форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка

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

"Релиз systemd 233"	+/–
Сообщение от opennews (??) on 02-Мрт-17, 13:57
После четырёх месяцев разработки сформирован (https://lists.freedesktop.org/archives/systemd-devel/2017-Ma...) выпуск системного менеджера systemd 233 (http://www.freedesktop.org/software/systemd/). Из новшеств можно отметить перенос правил DBus из /etc в /usr, добавление генератора переменных окружения, задействование гибридного режима настройки cgroup, новые опции монтирования в fstab, поддержка автоматической настройки для монтирования разделов LUKS и Verity, возможность сохранения backtrace при записи core-дампов. Основные изменения: -  Правила DBus теперь устанавливаются в иерархию /usr, а не в /etc. Для переопределения каталога следует использовать опцию "--with-dbuspolicydir="; -  Все поставляемые в составе systemd скрипты на языке Python (в основном то тестовые сценарии) теперь требуют для своей работы наличия Python 3; -  В .network-файлы  systemd-networkd добавлены новые параметры: В секцию "[DHCP]" добавлен параметр  "ListenPort=", позволяющий явно указать UDP-порт для приёма запросов DHCP-клиентом. Добавлен параметр "Unmanaged=" для вывода интерфейсов из управления systemd-networkd. Добавлен параметр "IPv6ProxyNDPAddress=" для настройки адреса  NDP Proxy для IPv6.  Добавлены опции "ActiveSlave=" и "PrimarySlave=" для опрелеления приоритетов при агрегировании сетевых интерфейсов. В блоге "[Match]" обеспечена возможность задания исключений (логическое "нет"); -  В /etc/fstab добавлены новые опции монтирования, специфичные для  systemd:  x-systemd.mount-timeout для ограничения максимального времени выполнения команды монтирования; x-systemd.device-bound для создания директории для монтирования  при появлении устройства (при отключении устройства, точка монтирования будет удалена); x-systemd.after и x-systemd.before для явного задания порядка монтирования (можно определить за или перед каким unit-ом или точкой монтирования следует выполнить монтирование текущего раздела); -  В таймерах (.timer unit) добавлена возможность указания времени относительно конца месяца через использование разделителя "~" вместо "-" между днём и месяцем. Например, "*-02~03"  приведёт к срабатыванию таймера за три дня до конца февраля. Также добавлен альтернативный синтаксис определения повторяющихся событий, например, "9..17/2:00" - запускать каждые два часа с 9 до 17 часов; -  Режим настройки cgroup теперь может выбираться на этапе загрузки через передачу ядру параметров  "systemd.unified_cgroup_hierarchy=" и        "systemd.legacy_systemd_cgroup_controller=", а также при компиляции через опцию "--with-default-hierarchy=". По умолчанию выставляется гибридный режим (устанавливается значение "hybrid"), но в будущем ожидается переход на унифицированную иерархию cgroups-v2 (groups-v2, значение "unified"). Для включения классического режима  (cgroups-v1) следует использовать значение "legacy". Дистрибутивам рекомендовано начиная с  systemd 233 выставлять режим "hybrid" для релизов, "unified" для экспериментальных сборок (например, для  Fedora rawhide) и "legacy" для достижения наилучшей совместимости и стабильности; -  Гибридный режим настройки cgroup (смесь cgroups-v2 и cgroups-v1) модифицирован для улучшения совместимости с классическими конфигурациями cgroups-v1. Состав /sys/fs/cgroup приближен к классической иерархии cgroups-v1, включая наличие /sys/fs/cgroup/systemd. Из ограничений гибридного режима по сравнению с унифицированной иерархией отмечается невозможность миграции процессов между двумя отделёнными поддеревьями cgroup для непривилегированных экземпляров systemd, запущенных в режиме "--user", даже если оба поддерева принадлежат одному пользователю (например, "systemd-run --user --scope" не будет работать при вызове вне текущего контекста "systemd --user"); -  В  systemd-nspawn добавлена возможность автоматической настройки шифрованных разделов LUKS и верифицированных разделов Verity - когда контейнер загружается с шифрованного раздела будет запрошен пароль доступа, а когда с раздела  Verity будет осуществлён поиск файла ".roothash" с проверочным хэшем; -  В systemd-fstab-generator добавлена проверка загрузки ядра с параметром "systemd.volatile=", что позволяет реализовать для обычных загрузок аналог режима "--volatile" в systemd-nspawn, позволяющем загрузить систему без предварительно подготовленных директорий /etc и /var, корневой раздел с этими директориями будет создан на лету в tmpfs, а из системных разделов примонтирован только /usr (если указать "systemd.volatile=state", то будет использован обычный корневой раздел, а в tmpfs будет примонтирован только /var); -  В unit-файлы добавлена новая опция "RootImage=", похожая на "RootDirectory=", но монтирующая директорию из заданного образа вместо использования существующей директории;-  В unit-файлы добавлена опция "MountAPIVFS=", осуществляющая монтирование /proc, /sys и /dev ("API VFS") для сервиса;-  В coredumpctl добавлена опция "--reverse" для вывода списка core-дампов в обратном порядке и возможность показа дампов, созданный в определённое время (опции "--since=" и "--until="). В coredumpctl также обеспечен вывод дополнительной информации об обрезанных, недоступных и сохраняемых в данный момент core-дампах. В  systemd-coredump  добавлены средства для выполнения обратной трассировки (backtrace) для интерпретируемых языков, например, для скриптов на Python; -  Добавлена опциональная возможность запуска исполняемых файлов для генерации переменных окружения на стадии загрузки конфигурации, что может быть использовано для добавления переменных окружения для запускаемых сервисов. По умолчанию поставляется генератор переменных окружения, использующих значения их каталогов /etc/environment.d и ~/.config/environment.d/; -  Реализована возможность обособленного запуска unit-тестов, не требующая наличия исходных текстов systemd и сборочного окружения. Тесты устанавливаются в каталог /usr/lib/systemd/tests/ и запускаются командой 'make install-tests'; -  Начиная с выпуска 233 для работы  systemd  в ядре Linux должны быть включены опции  CONFIG_CRYPTO_USER_API_HASH, CONFIG_CRYPTO_HMAC и CONFIG_CRYPTO_SHA256; -  В unit-файлах прекращена поддержка спецификаторов  "%c", "%r" и "%R"; -  При вызове службы debug-shell.service в качестве командной оболочки по умолчанию теперь всегда используется  /bin/sh. Для настройки другой оболочки, например, /sbin/sushell, можно использовать сборочную опцию "--with-debug-shell="; -  Изменён список вариантов действий, выводимых при необходимости подтверждения запуска команды:            (c)ontinue, proceed without asking anymore            (D)ump, show the state of the unit            (f)ail, don't execute the command and pretend it failed            (h)elp            (i)nfo, show a short summary of the unit            (j)obs, show jobs that are in progress            (s)kip, don't execute the command and pretend it succeeded            (y)es, execute the command Вариант "n" (No) удалён, чтобы не вводить в заблуждение. Свою реализацию диалога можно можно настроить через параметр "systemd.confirm_spawn="; -  Для сервисов, которые не смогли корректно запуститься из-за сбоя, теперь всегда вызывается команда "ExecStopPost=" (раньше сервис оставался в состоянии "failed" без запуска команд остановки); -  Добавлена реализация MulticastDNS, включаемая командой "MulticastDNS=yes"; -  В systemd-analyze добавлена команда "syscall-filter", позволяющая увидеть, какие группы системных вызовов определены в настройках unit-файлов (SystemCallFilter); -  Добавлены новые группы системных вызовов: "@filesystem", охватывающая системные вызовы, связанные с работой файловых систем; "@reboot" для вызовов, связанных с перезагрузкой и завершением работы; "@swap" для системных вызовов по настройке раздела подкачки; -  Добавлен новая опция unit-файлов  "RestrictNamespaces=", предназначенная для ограничения доступа к различным типам пространствам имён, например, можно запр... URL: https://lists.freedesktop.org/archives/systemd-devel/2017-Ma... Новость: https://www.opennet.ru/opennews/art.shtml?num=46123
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

2. "Релиз systemd 233"	+6 +/–
Сообщение от Аноним (??) on 02-Мрт-17, 14:00
Может кто-нибудь внятно объяснить зачем: > перенос правил DBus из /etc в /usr
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Релиз systemd 233"	+1 +/–
	Сообщение от Andrey Mitrofanov on 02-Мрт-17, 14:10
	> Может кто-нибудь внятно объяснить зачем: >> перенос правил DBus из /etc в /usr Видимо, https://www.freedesktop.org/software/systemd/man/systemd.uni... строят свой замок слоновой кости, чтоб всё чинно, рядками, как у бальших.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	6. "Релиз systemd 233"	+4 +/–
	Сообщение от Мадара (ok) on 02-Мрт-17, 14:26
	> В systemd-fstab-generator добавлена проверка загрузки ядра с параметром "systemd.volatile=", что позволяет реализовать для обычных загрузок аналог режима "--volatile" в systemd-nspawn, позволяющем загрузить систему без предварительно подготовленных директорий /etc и /var, корневой раздел с этими директориями будет создан на лету в tmpfs, а из системных разделов примонтирован только /usr; думаю это взаимосвязанно
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	13. "Релиз systemd 233"	+1 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 14:45
	Этой идее уже сто лет^W три года https://www.opennet.ru/opennews/art.shtml?num=40132
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	172. "Релиз systemd 233"	+4 +/–
	Сообщение от foo on 03-Мрт-17, 15:15
	сто три года? О_О
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	124. "Релиз systemd 233"	+3 +/–
	Сообщение от Kroz (ok) on 03-Мрт-17, 01:10
	> а из системных разделов примонтирован только /usr; Так, стоп! Так /usr можно на отдельном разделе? https://freedesktop.org/wiki/Software/systemd/separate-usr-i.../
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	10. "Релиз systemd 233"	+13 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 14:42
	> Может кто-нибудь внятно объяснить зачем: >> перенос правил DBus из /etc в /usr Это такая схема размещения конфигов. Дефолтные (дистрибутивные) конфиги лежат в /usr. Если админ хочет что-то поменять, он копирует их в /etc и правит там. /etc имеет приоритет над /usr. В принципе логично и удобно. Для тех программ, которые эту схему не используют, лично я стараюсь копировать дефолтный конфиг перед правкой, чтобы в случае чего быстро откатить обратно. А так достаточно удалить свой файл из /etc.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	125. "Релиз systemd 233"	+3 +/–
	Сообщение от Kroz (ok) on 03-Мрт-17, 01:16
	> Это такая схема размещения конфигов. Дефолтные (дистрибутивные) конфиги лежат в /usr. Если > админ хочет что-то поменять, он копирует их в /etc и правит > там. /etc имеет приоритет над /usr. C такой логикой нужно весь /etc в /usr засунуть. Кейс: С очередным обновлением приходит апдейт конфигов в /usr, и получается что "админовская версия" (точнее её части, которые были модифицированы в апдейте) уже не актуальны. Как с этим предлагается работать? Если всё в /etc, то пакетный менеджер обнаруживает, что файл был изменен админом, кладет новую версию конфига рядом, и выводит сообщение админу "смерджи, пожалуйста". А с вариантом "конфиги в /usr" как?
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	140. "Релиз systemd 233"	+4 +/–
	Сообщение от Аноним (??) on 03-Мрт-17, 09:40
	Дурной вопрос. Каждый правоверный обязан читать бложек своего пророка на предмет новых откровений.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	145. "Релиз systemd 233"	+/–
	Сообщение от Аноним (??) on 03-Мрт-17, 09:55
	Точно так же.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	12. "Релиз systemd 233"	+10 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 14:44
	потому что в /usr должны лежать конфиги системы, написанные майнтейнерами и приезжающие из пакетов, а в /etc - локальные, написанные админом.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	18. "Релиз systemd 233"	–5 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 15:13
	А когда я ищу действующий конфиг, я куда должен лезть? В место А, если нет Б, если нет С, если нет Д, если нет - бл*, я за---лся!
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	59. "Релиз systemd 233"	–1 +/–
	Сообщение от XXXasd (ok) on 02-Мрт-17, 18:54
	> я куда должен лезть? а куда ты его клал? ни куда? тогда в /usr/
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	62. "Релиз systemd 233"	+/–
	Сообщение от Аноним (??) on 02-Мрт-17, 19:08
	Вы что, единственный админ в ойкумене?
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	117. "Релиз systemd 233"	+1 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 23:48
	> Вы что, единственный админ в ойкумене? А вы что, не знакомы с системами, которые администрируете?
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	127. "Релиз systemd 233"	+1 +/–
	Сообщение от RomanCh (ok) on 03-Мрт-17, 01:26
	Тут такое дело, что на практике иногда действительно так и бывает. Иногда впервые заходишь на машину которую до тебя настраивали несколько поколений админов (и программистов!) разной степени вменяемости и компетентности. Да, в теории конечно "вы же должны всё изучить и знать!" но на практике: * На это чаще всего просто нет времени. * О существовании некоторых машин вы узнаёте только когда они ломаются, т.к. передача проекта была осуществлена на уровне "вот вам xls файл, в нём всё описано!"
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	171. "Релиз systemd 233"	+/–
	Сообщение от freehck (ok) on 03-Мрт-17, 15:14
	> * На это чаще всего просто нет времени. > * О существовании некоторых машин вы узнаёте только когда они ломаются, т.к. > передача проекта была осуществлена на уровне "вот вам xls файл, в > нём всё описано!" Ну, это скорее организационные проблемы. К тому же, в системах с systemd этого нет лишь потому что они покамест довольно молоды: подождём лет десять, и будут те же самые проблемы. Тут даже дело не в степени адекватности предыдущих поколений админов, сколько в адекватности разработчиков данного инструмента.
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	178. "Релиз systemd 233"	–3 +/–
	Сообщение от Аноним (??) on 03-Мрт-17, 16:59
	> в системах с systemd этого нет systemd уже 6 лет и проблем нет. Вы предлагаете ждать 16 лет (6+10) чтобы понять что правильная архитектура привела к полному решению нагноившейся проблемы? Долго же до вас доходит...
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	180. "Релиз systemd 233"	+/–
	Сообщение от freehck (ok) on 03-Мрт-17, 17:51
	>> в системах с systemd этого нет > systemd уже 6 лет и проблем нет. Как же. В 2014-2015м systemd имел тенденцию падать в сегфолт при выполнении элементарных операций, но это ж не проблема, что это я в самом деле. Хотите пруфлинк дам? Надо всего лишь зайти в архив debian-russian. :)
	Ответить | Правка | ^ к родителю #178 | Наверх | Cообщить модератору

	219. "Релиз systemd 233"	–2 +/–
	Сообщение от yz on 05-Мрт-17, 11:25
	рассматривать systemd из debian смешно, они там на десятки версий отстают. Когда это давно починили в апстрими, вы получите обновление в следующем релизе. В debian странно поступили пытаются поддерживать функциональность systemd, пытаешься начинать использоваться и тут выясняется что версия настолько древняя в которой бага или просто функционал на начальном уровне. В redhat хотябы зарезали такой функционал, чтобы даже не пытался настраивать и делал и как раньше
	Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

	220. "Релиз systemd 233"	+1 +/–
	Сообщение от freehck (ok) on 05-Мрт-17, 12:34
	О, знакомая песня. :) https://opennet.ru/opennews/art.shtml?num=43862#62
	Ответить | Правка | ^ к родителю #219 | Наверх | Cообщить модератору

	225. "Релиз systemd 233"	+/–
	Сообщение от yz on 06-Мрт-17, 16:20
	Тут получается одни не могут сделать стабильную ветку, другие вкорячили а поддерживать до конца не в силах.
	Ответить | Правка | ^ к родителю #220 | Наверх | Cообщить модератору

	226. "Релиз systemd 233"	+2 +/–
	Сообщение от Аноним (??) on 06-Мрт-17, 17:48
	Но разве вкорячивание не аргументировалось тем, что бедным мейнтейнерам станет проще все поддерживать?
	Ответить | Правка | ^ к родителю #225 | Наверх | Cообщить модератору

	230. "Релиз systemd 233"	+/–
	Сообщение от freehck (ok) on 06-Мрт-17, 23:50
	Оба правы. :)
	Ответить | Правка | ^ к родителю #226 | Наверх | Cообщить модератору

	201. "Релиз systemd 233"	+1 +/–
	Сообщение от . on 04-Мрт-17, 20:06
	>systemd уже 6 лет и проблем нет. В Багдаде всё спокойно :) Вот только ты забыл что тут у людей и опыт и интернет таки есть ... Так что мир-дверь-мяч ты :)
	Ответить | Правка | ^ к родителю #178 | Наверх | Cообщить модератору

	232. "Релиз systemd 233"	–1 +/–
	Сообщение от дуайт эйзенхауер on 10-Мрт-17, 01:25
	В паппет, ёпрст.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	65. "Релиз systemd 233"	+/–
	Сообщение от freehck (ok) on 02-Мрт-17, 19:16
	> потому что в /usr должны лежать конфиги системы, написанные майнтейнерами и приезжающие из пакетов, а в /etc - локальные, написанные админом. Ага. Мой любимый с некоторых пор вопрос: что такое "конфиги" в этом контексте? А то однажды разговаривали-разговаривали о конфигах, а потом выяснилось, что это не конфиги демонов, а их .unit-файлы. А всё почему? Потому что дефолтные конфиги от мейнтейнеров (которые именно конфиги демонов), могут оказаться разными, в зависимости от ряда факторов.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	102. "Релиз systemd 233"	+2 +/–
	Сообщение от freehck (ok) on 02-Мрт-17, 22:45
	>> потому что в /usr должны лежать конфиги системы, написанные майнтейнерами и приезжающие из пакетов, а в /etc - локальные, написанные админом. > Ага. Мой любимый с некоторых пор вопрос: что такое "конфиги" в этом контексте? Угу. И гробовое молчание. Конечно, ведь если ответить на этот вопрос, то встанет следующий: Понятно, почему юниты, являющиеся конфигурационными файлами для systemd, лежат в /usr. Не понятно, почему там должны лежать правила dbus, которые являются конфигурацией, внезапно, dbus.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	106. "Релиз systemd 233"	–4 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 23:29
	> Понятно, почему юниты, являющиеся конфигурационными файлами для systemd, лежат в /usr. Не понятно, почему там должны лежать правила dbus, которые являются конфигурацией, внезапно, dbus. Потому что эта схема логична, понятна и удобна для абсолютного большинства конфигов.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	142. "Релиз systemd 233"	+2 +/–
	Сообщение от Аноним (??) on 03-Мрт-17, 09:43
	> Потому что эта схема логична, понятна и удобна для абсолютного большинства конфигов. конфиги стали обладать мышлением? 8-( я уже опасаюсь systemd
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	193. "Релиз systemd 233"	–3 +/–
	Сообщение от anomymous on 04-Мрт-17, 14:47
	Да, и интеллект systemd начал превосходить интеллект многих среднестатистических админчиков локалхостов, привыкших к vi и вороху дерьма в /etc/init.d
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	198. "Релиз systemd 233"	+1 +/–
	Сообщение от Аноним (??) on 04-Мрт-17, 16:08
	> Да, и интеллект systemd начал превосходить интеллект многих среднестатистических админчиков > локалхостов, привыкших к vi и вороху дерьма в /etc/init.d сам-то каким парком рулишь? судя по апломбу - два сервера в бухгалтерии и один прокси? :)))))))))
	Ответить | Правка | ^ к родителю #193 | Наверх | Cообщить модератору

	202. "Релиз systemd 233"	+/–
	Сообщение от . on 04-Мрт-17, 20:08
	И все три виндоуз :)
	Ответить | Правка | ^ к родителю #198 | Наверх | Cообщить модератору

	107. "Релиз systemd 233"	–2 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 23:31
	> Ага. Мой любимый с некоторых пор вопрос: что такое "конфиги" в этом контексте? > А то однажды разговаривали-разговаривали о конфигах, а потом выяснилось, что это не конфиги демонов, а их .unit-файлы. Юнит-файлы - частный случай файлов конфигурации (в данном случае - файлов конфигурации systemd). Файлы конфигурации D-Bus - другой частный случай. А схема etc over usr работает понятно и прозрачно в обоих случаях, и во многих других.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	148. "Релиз systemd 233"	+/–
	Сообщение от freehck (ok) on 03-Мрт-17, 10:24
	> А схема etc over usr работает понятно и прозрачно в обоих случаях, и во многих других. Между прочим, "работает понятно и прозрачно" - это тот вопрос, на который я потратил очень много времени, чтобы оно так и было. Но вот ответьте мне: а в чём собственно цимес? Ну можете вы откатиться, потому что у вас в /usr файлы с дефолтами всегда остаются. Но зачем? Что, вы так много юнитов меняете? Если нет, то не проще ли сделать бэкап редактируемого юнита? Ну можете вы строить диффы конфигурации systemd. А толку? Смотреть диффы имеет смысл только тому, кто дефолты хорошо знает. А дефолты systemd, судя по новостям, меняются каждую версию. PS: по поводу "многих других" случаев я даже не стану спрашивать какие. Их наверняка тысячи, у них у всех однотипно составлены конфиги и разумеется не более одного дефолтного конфига от мейнтейнера.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	217. "Релиз systemd 233"	+1 +/–
	Сообщение от Vkni (ok) on 04-Мрт-17, 22:57
	> Если нет, то не проще ли сделать бэкап редактируемого юнита? Кстати, если backup продолбан, пакет всегда можно скачать ещё один раз из репозитария, и переустановить, восстановив конфиг maintainer'а. Или просто вытащить из .rpm/.deb с помощью mc или утилит командной строки.
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

	126. "Релиз systemd 233"	+1 +/–
	Сообщение от Kroz (ok) on 03-Мрт-17, 01:19
	> потому что в /usr должны лежать конфиги системы, написанные майнтейнерами и приезжающие > из пакетов, а в /etc - локальные, написанные админом. C такой логикой нужно весь /etc в /usr засунуть. Кейс: С очередным обновлением приходит апдейт конфигов в /usr, и получается что "локальная версия" (точнее её части, которые были модифицированы в апдейте) уже не актуальны. Как с этим предлагается работать? Если всё в /etc, то пакетный менеджер обнаруживает, что файл был изменен админом, кладет новую версию конфига рядом, и выводит сообщение админу "смерджи, пожалуйста". А с вариантом "конфиги в /usr" как?
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	149. "Релиз systemd 233"	+/–
	Сообщение от freehck (ok) on 03-Мрт-17, 10:30
	> Кейс: С очередным обновлением приходит апдейт конфигов в /usr Ты им ещё раскрой большой секрет, пакет может предоставлять несколько дефолтных конфигов в зависимости от цели установки. За примерами тоже далеко ходить не надо: apt-get install postfix. Ох, Kroz, знаешь, сколько таких разговоров у меня уже было? :) Не парься, они не слушают.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	216. "Релиз systemd 233"	+/–
	Сообщение от Vkni (ok) on 04-Мрт-17, 22:54
	> C такой логикой нужно весь /etc в /usr засунуть. Я подозреваю, что там один кадр забыл, что есть репозитарии, из которых всегда можно вытащить изначальный пакетный конфиг вместе с самим пакетом. Или вообще не догадывался об этом, т.к. пришёл с MS Windows.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	233. "Релиз systemd 233"	+/–
	Сообщение от freehck (ok) on 10-Мрт-17, 06:31
	>> C такой логикой нужно весь /etc в /usr засунуть. > Я подозреваю, что там один кадр забыл, что есть репозитарии, из которых > всегда можно вытащить изначальный пакетный конфиг вместе с самим пакетом. Или > вообще не догадывался об этом, т.к. пришёл с MS Windows. Он что-то говорил на тему "давайте заменим пакетный менеджер на btrfs". Может быть ему понравились снапшоты btrfs? Зная Поттеринга, видение его могло бы быть примерно таким: systemd мониторит появление новых и изменения старых юнитов и каждый раз при обнаружении оных делает снапшот.
	Ответить | Правка | ^ к родителю #216 | Наверх | Cообщить модератору

	215. "Релиз systemd 233"	+/–
	Сообщение от Vkni (ok) on 04-Мрт-17, 22:52
	> потому что в /usr должны лежать конфиги системы, написанные майнтейнерами и приезжающие > из пакетов, а в /etc - локальные, написанные админом. А зачем нужны конфиги системы, написанные "майнтейнерами", если есть сисадминские? Это я как maintainer спрашиваю.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	44. "Релиз systemd 233"	+1 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 18:10
	> перенос правил DBus из /etc в /usr Надо чаще так делать. В следующем релизе нужно вернуть обратно.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	58. "Релиз systemd 233"	+/–
	Сообщение от Andrey Mitrofanov on 02-Мрт-17, 18:53
	>> перенос правил DBus из /etc в /usr > Надо чаще так делать. В следующем релизе нужно вернуть обратно. В следующем будут "/usr merge" для снова образовавшийся /usr топтать. Эта музыка будет вечной!
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

9. "Релиз systemd 233"	+2 +/–
Сообщение от AlexGluck on 02-Мрт-17, 14:36
А зачем замена fstab, cron, lxc, docker, networkmanager, chroot, rsyslog, resolv, udev, login и я заманался вычитывать что там ещё есть? Я был противником системд как раз из-за того что в него пихают всё подряд. Но действительно на многопоточных конфигурациях не хватало современной замены систем5. Если добавить ядро ОС и coreutils практически готовый дистрибутив.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	14. "Релиз systemd 233"	+/–
	Сообщение от Аноним (??) on 02-Мрт-17, 14:46
	> на многопоточных конфигурациях Каких, простите?
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	16. "Релиз systemd 233"	–6 +/–
	Сообщение от AlexGluck on 02-Мрт-17, 14:55
	Многопоточных - много потоков. Это, уважаемый динозавр, когда у компьютера потоков исполнения задач больше 1. Например технология HT от intel или больше одного ядра у процессора. Каждая задача выполняется в своём потоке и в зависимости от количества потоков, одновременно могут стартовать монтирование шар, настройка сети, внутренних систем.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	20. "Релиз systemd 233"	+/–
	Сообщение от 123 (??) on 02-Мрт-17, 15:35
	>> Например технология HT от intel HT это просто хитро закрученный конвейер c блоком регистров вместо еще одного ядра.   >>Каждая задача выполняется в своём потоке Неправильный ответ в отношении systemd, он просто хорошо оптимизирует запуск сервисов, учитывая их зависимости - копия scm от ms, который копия старта из netware.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	86. "Релиз systemd 233"	–3 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 21:24
	>> HT это просто хитро закрученный конвейер c блоком регистров вместо еще одного ядра.   Не совсем, всё сложнее. Процессор определяется как два и забирает себе инструкции двух разных потоков. Суть в том, что каждая инструкция разбивается на микрокоманды и формируется очередь микрокоманд для каждого потока. Так как две очереди по большей части не зависят друг от друга, то их микрокоманды могут идти на разные исполнительные блоки процессора и обрабатываться параллельно. Мало того, конвейер угадывает будущее, т.е. обрабатывает микрокоманды наперёд, максимально задействуя все вычислительные блоки, какие возможно. Всё это вместе взятое позволяет на порядок повысить производительность, не прибегая к повышению частоты процессора.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	131. "Релиз systemd 233"	+5 +/–
	Сообщение от Аноним (??) on 03-Мрт-17, 02:53
	Вы бы все хоть писали в одной терминологии. Ваш "поток" - это английское "thread" - термин, используемый при переводе документации для программирования в среде Windows (!). В среде Линукс термин "thread" переводят как "нити". Но это всё в прикладном (!) программировании. Когда речь заходит о процессорах, используется терминология Интел. Никаких "потоков" и "микрокоманд" там нет. Процессор вообще ничего не знает о "потоках". > конвейер угадывает будущее Не угадывает, а предсказывает. И не будущее, а переходы. В Intel Pentium он предполагал, что в условии если-то (истина-ложь) наиболее вероятен тот переход, который произошёл в прошлый раз. Начиная с Intel Pentium 2 для предсказания используются 3 последних перехода, предполагая что переход будет туда, куда произошли два из трёх. > не прибегая к повышению частоты процессора Это вообще отдельная тема, в которой ты явно не шаришь. > позволяет на порядок повысить производительность Весьма спорно. HT даёт процентов 10-20% в ненагруженных задачах и замедляет (!) выполнение при нагрузке свыше 60% (угадай почему). И нужен он для другого, а конкретно - писькометрии количеством ядер (маркетинг, десу) и сглаживаем просадок если в ОС не смогли реализовать нормальный балансировщик нагрузки (Линукс, десу).
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	182. "Релиз systemd 233"	+/–
	Сообщение от Аноним (??) on 03-Мрт-17, 18:44
	>> "микрокоманд" там нет. Да ну? Я системный разработчик и интересуюсь оптимизацией под процессоры, соответственно. Ваше заявление относится к процессорам 10-летней давности. На всё ваше сообщение я могу посоветовать Вам почитать хотя бы Архитектуру ЭВМ Таненбаума. Ну или пошерстить по статьям Википедии, если книга напугает размером.
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	185. "Релиз systemd 233"	+/–
	Сообщение от Аноним (??) on 03-Мрт-17, 21:29
	И ещё, после того, как изучите вопрос, ответьте на вопрос: какая в этом десятилетии была самая главная задача разработчиков процессоров? Если правильно ответите на вопрос, считайте, что вы уже в теме. Могу подсказать ответ, - он связан с исполнением микрокоманд (или микроинструкций, как вам угодно), которых "там нет" .
	Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

	203. "Релиз systemd 233"	–1 +/–
	Сообщение от . on 04-Мрт-17, 20:11
	>Я системный разработчик и интересуюсь оптимизацией под процессоры, Да нет, ты - очередная "дочь морского офицера", у которой "тут всё не так однозначно" :) Иди к лужам и береди им душу :-)
	Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

	194. "Релиз systemd 233"	–1 +/–
	Сообщение от anomymous on 04-Мрт-17, 14:51
	Не для писькометрии и не из-за балансировщика он нужен. Он нужен, чтобы увеличить загрузку существующих исполнительных блоков, и не делать ради большего параллелизма ещё одно честное ядро. А почему честное ядро не хотят делать - знаете? Нет, не стоимость.
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	209. "Релиз systemd 233"	+/–
	Сообщение от Аноним (??) on 04-Мрт-17, 20:40
	Не томи!!!
	Ответить | Правка | ^ к родителю #194 | Наверх | Cообщить модератору

	210. "Релиз systemd 233"	–1 +/–
	Сообщение от Аноним (??) on 04-Мрт-17, 20:40
	Приятно видеть, что здесь есть люди с которыми можно что-либо пообсуждать. Мне теперь и самому интересно, почему больше ядер не делают. Сам я над этим не задумывался никогда. Думаете, для удержания энергопотребления на низком уровне?
	Ответить | Правка | ^ к родителю #194 | Наверх | Cообщить модератору

	46. "Релиз systemd 233"	+/–
	Сообщение от Аноним (??) on 02-Мрт-17, 18:18
	Внезапно, "монтирование шар, настройка сети, внутренних систем" выполняется практически с той же скоростью вне зависимости от количества потоков, исполняемых вашим CPU одновременно.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	24. "Релиз systemd 233"	+/–
	Сообщение от Аноним (??) on 02-Мрт-17, 15:55
	/etc/fstab как был, так и остался cron с этим "crontab -e" - все правильно сделали lxc - более низкий уровень, используется в systemd docker - появился на 3 года позже systemd, имеет проблемы с безопасностью, другое предназначение networkmanager - кусок крапа, все правильно сделали и т.д.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	25. "Релиз systemd 233"	+1 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 16:01
	Если бы не пихали всё в одно - слова бы никто не говорил. > cron с этим "crontab -e" - все правильно сделали Меня всё устраивает. > networkmanager - кусок крапа, все правильно сделали Что это такое вообще и почему это должно быть у меня в системе? Точнее почему оно отсутствует?
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	108. "Релиз systemd 233"	–3 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 23:34
	>> cron с этим "crontab -e" - все правильно сделали > Меня всё устраивает. Это ваши личные проблемы. А вот мейнтейнеры дебиана, например, задолбались писать костыли типа > # By default, run at 00:57 on every Sunday, but do nothing unless the day of > # the month is less than or equal to 7. Thus, only run on the first Sunday of > # each month. crontab(5) sucks, unfortunately, in this regard; therefore this > # hack (see #380425). > 57 0 * * 0 root if [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	150. "Релиз systemd 233"	+2 +/–
	Сообщение от freehck (ok) on 03-Мрт-17, 10:38
	>>> cron с этим "crontab -e" - все правильно сделали >> Меня всё устраивает. > Это ваши личные проблемы. А вот мейнтейнеры дебиана, например, задолбались писать костыли > типа >> # By default, run at 00:57 on every Sunday, but do nothing unless the day of >> # the month is less than or equal to 7. Thus, only run on the first Sunday of >> # each month. crontab(5) sucks, unfortunately, in this regard; therefore this >> # hack (see #380425). >> 57 0 * * 0 root if [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi Неа. Это не проблемы, а достоинства cron-а. Если что-то не предусмотрено в systemd - "у вас не должно быть такой задачи", "мы такое не поддерживаем", "уходите, не вешайте нам больше таких багов". Ах да, и "get off ma lawn". Если что-то не предусмотрено в crontab - "ребята, напишите shell скрипт, с парой дополнительных проверок, и всё будет зашибись".
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

17. "Релиз systemd 233"	–2 +/–
Сообщение от Аноним (??) on 02-Мрт-17, 15:12
> Начиная с выпуска 233 для работы systemd в ядре Linux должны быть включены опции CONFIG_CRYPTO_USER_API_HASH, CONFIG_CRYPTO_HMAC и CONFIG_CRYPTO_SHA256; А говорят приложение не может требовать опций ядра..
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	22. "Релиз systemd 233"	+/–
	Сообщение от Аноним (??) on 02-Мрт-17, 15:39
	А еще приложений можно сразу много запустить, и они хранят документы в $HOME. А тут какие то /usr и /etс... Что за мерзость, действительно - опции ядра, системные файлы. Даешь только кнопку "Сделать зае__сь", и не надо никаких системд.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	27. "Релиз systemd 233"	+3 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 16:06
	> Даешь только кнопку "Сделать зае__сь" Прекрасное описание работы systemd. Зачем думать? Там же все юниты за тебя всё делают, настраивают, запускают сервисы.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	26. "Релиз systemd 233"	–1 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 16:04
	>> Начиная с выпуска 233 для работы systemd в ядре Linux должны быть включены опции CONFIG_CRYPTO_USER_API_HASH, CONFIG_CRYPTO_HMAC и CONFIG_CRYPTO_SHA256; > А говорят приложение не может требовать опций ядра.. Этот комбайн ещё не того потребует скоро. Они форкнут ядро и включат всё в него. А потом оно так разрастётся, что останется один бинарь, который умеет ВСЁ.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	110. "Релиз systemd 233"	+/–
	Сообщение от Аноним (??) on 02-Мрт-17, 23:38
	>> Начиная с выпуска 233 для работы systemd в ядре Linux должны быть включены опции CONFIG_CRYPTO_USER_API_HASH, CONFIG_CRYPTO_HMAC и CONFIG_CRYPTO_SHA256; > А говорят приложение не может требовать опций ядра.. Скажите это разработчикам LXC, Docker, iptables, DRBD, ipvs, brctl, tgtd, mdadm и десятков других программ, а то они как-то не в курсе :)
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

19. "Релиз systemd 233"	–4 +/–
Сообщение от Аноним (??) on 02-Мрт-17, 15:31
админ локал хоста из вижу пока из пользы что комп мнгновенно выключается пока одобряю но не понятно как в логах копатся куда они делись, документация портянка лучше стар трек посмотреть
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	23. "Релиз systemd 233"	–1 +/–
	Сообщение от Проходя мимо on 02-Мрт-17, 15:55
	Зачем вам линукс если вы не можете забить в гугл systemd logging?
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	28. "Релиз systemd 233"	+8 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 16:09
	> Зачем вам линукс если вы не можете забить в гугл systemd logging? Зачем мне гуглить, если без systemd у меня все логи в /var/log?
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	91. "Релиз systemd 233"	+/–
	Сообщение от EuPhobos (ok) on 02-Мрт-17, 21:35
	А с сюстемде они у вас в оперативке по умолчанию, после ребута journalctl всегда девственник. Так то.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	37. "Релиз systemd 233"	+/–
	Сообщение от Аноним (??) on 02-Мрт-17, 17:27
	Для локалхоста и мелких серверов всё-же проще в текстовики, ротацию только всему по умолчанию навязать :)
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	67. "Релиз systemd 233"	+/–
	Сообщение от freehck (ok) on 02-Мрт-17, 19:24
	> Для локалхоста и мелких серверов всё-же проще в текстовики, ротацию только всему по умолчанию навязать :) Это в каком-таком дистрибутиве на /var/log не натравлен ротатор по умолчанию? :)
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	75. "Релиз systemd 233"	+/–
	Сообщение от Andrey Mitrofanov on 02-Мрт-17, 19:43
	> Это в каком-таком дистрибутиве на /var/log не натравлен ротатор по умолчанию? :) Ставишь Debian. И не ставишь logrotate. Учись, студент! :D
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	96. "Релиз systemd 233"	+/–
	Сообщение от freehck (ok) on 02-Мрт-17, 22:11
	>> Это в каком-таком дистрибутиве на /var/log не натравлен ротатор по умолчанию? :) > Ставишь Debian. И не ставишь logrotate. Учись, студент! :D Package: logrotate Priority: important https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.... > *Important* packages should be found on any Unix-like system. > Other packages which the system will not run well or be usable without will be here. Короче, это ж ещё додуматься надо! :) И по-любому он вместе с minimal-install ставится, ибо я всегда ставлюсь через debootstrap, и никогда отдельно logrotate не ставил - сам прилетал.
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	121. "Релиз systemd 233"	+/–
	Сообщение от Аноним (??) on 02-Мрт-17, 23:54
	> Для локалхоста и мелких серверов всё-же проще в текстовики Почему? Как по мне, так даже на локалхосте journalctl с фишками типа -b-1, --since и --until гораздо удобнее костылей на грепе.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	204. "Релиз systemd 233"	+/–
	Сообщение от . on 04-Мрт-17, 20:15
	Дуууу ... а шаг в сторону и тебе стреляют в голову! Иди в >|< - если мне нужна будет огороженность - винда и так уже существует.
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

21. "Релиз systemd 233"	+1 +/–
Сообщение от Аноним (??) on 02-Мрт-17, 15:38
когда уже Поттеринг свое ядро запилит
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	30. "Релиз systemd 233"	–1 +/–
	Сообщение от Andrey Mitrofanov on 02-Мрт-17, 16:20
	> когда уже Поттеринг свое ядро запилит "Мы" уж скорее hurd до десктопа допилим.    Фришники точно GNU&GPL из базы быстрее выкинут.       А потом, кому юникс-шел сложен, слаб для писания ядра, нет? А редхату https://www.dwheeler.com/essays/linux-kernel-cost.html#results слабО "своё" ядро "поднять". Денег у них столько нет. (Столько денег даже у мс нет.)  Рх только опенсорсные поделки монетизируют. И безобразничает и мелко пакостит с init-pid1-ами/udev-ами и прочими "free"desktop-ами, партнёрит с ораклами и майкрософтами и прочими мпеглами. Вал по плану и пр.СУБЖ.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	53. "Релиз systemd 233"	+/–
	Сообщение от Аноним (??) on 02-Мрт-17, 18:40
	А что сейчас происходит с SysVinit и какие перспективы?
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	60. "Релиз systemd 233"	+2 +/–
	Сообщение от Andrey Mitrofanov on 02-Мрт-17, 18:57
	> А что сейчас происходит с SysVinit и какие перспективы? Он просто работает. Причем и на машинах с субжом. Прикинь, да??    Про переспективы -- спроси в профильной новости об его новом%-S релизе.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	61. "Релиз systemd 233"	+/–
	Сообщение от Аноним (??) on 02-Мрт-17, 19:05
	И systemd тоже просто работает. Никаких причин менять одно на другое нет. Но у systemd есть перспективы, а у sysvinit если они и есть, то о них знают только очень информированные и глубоко законспирированные члены форума.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	66. "Релиз sнинужноd 233"	–2 +/–
	Сообщение от Andrey Mitrofanov on 02-Мрт-17, 19:18
	> И systemd тоже просто работает. Враньёёооо.... >Никаких причин менять одно на другое нет. Есть! И это та же причина, по которой Рх его всем вкорячивают. > Но у systemd есть перспективы, а у sysvinit если они и есть, Враньёёооо. > то о них знают только очень информированные и глубоко законспирированные члены > форума. Враньёо.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	81. "Релиз sнинужноd 233"	+1 +/–
	Сообщение от Мемасик on 02-Мрт-17, 21:03
	Нельзя ли аргументированно? Похож на бабку в церкви.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	112. "Релиз sнинужноd 233"	+/–
	Сообщение от Аноним (??) on 02-Мрт-17, 23:41
	> Нельзя ли аргументированно? Похож на бабку в церкви. Ну так sysvinit - это духовная скрепа юникса! В нее надо просто верить, все эти дискуссии и аргументации - от лукавого.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	69. "Релиз systemd 233"	–5 +/–
	Сообщение от freehck (ok) on 02-Мрт-17, 19:28
	> И systemd тоже просто работает. Никаких причин менять одно на другое нет. У systemd только одна перспектива: его проталкивает "Красная Шапочка". А по поводу того, что оно "просто работает", так это враньёёёёооо: https://www.opennet.ru/base/sys/systemd_myth.txt.html
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	95. "Релиз systemd 233"	–1 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 21:59
	По ссылке явно про старую версию. В новой же всё не так. И когда вы напишите про новую, то уже к тому времени выпустят следующую и всё опять изменится. systemd унаследовал критическую неуязвимость от своего создателя.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	99. "Релиз systemd 233"	+2 +/–
	Сообщение от freehck (ok) on 02-Мрт-17, 22:16
	> По ссылке явно про старую версию. Единственное, во что я поверю, так это в то, что Вы прочитали дату публикации исходной статьи, которая состоялась в 2014м году. Сам текст Вы даже взглядом не удостоили. Там, понимаете ли, про дизайн и общий подход. К конкретной версии не привязано.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	113. "Релиз systemd 233"	–2 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 23:43
	> Там, понимаете ли, про дизайн и общий подход. К конкретной версии не привязано. И что характерно, ни одного технического аргумента. Сплошное "я художник, я так вижу".
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	141. "Релиз systemd 233"	+/–
	Сообщение от freehck (ok) on 03-Мрт-17, 09:43
	> И что характерно, ни одного технического аргумента. Опять не читал. Анонимы такие анонимы. :)
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	164. "Релиз systemd 233"	+2 +/–
	Сообщение от Аноним (??) on 03-Мрт-17, 14:08
	> И что характерно, ни одного технического аргумента. Сплошное "я художник, я так > вижу". В код системды хоть раз смотрел? strcpy(mempcpy(mempcpy(r, f, a + 1), i, b), e); ... arg_header = strdup(option+7); ... strcpy(mempcpy(mempcpy(r, f, a + 1), i, b), e); ... ret = new(char, (e - slice) + 1 + strlen(name) + 6 + 1);
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	132. "Релиз systemd 233"	+/–
	Сообщение от Аноним (??) on 03-Мрт-17, 02:55
	Когда веруешь, аргумент не нужны.
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	143. "Релиз systemd 233"	+/–
	Сообщение от freehck (ok) on 03-Мрт-17, 09:46
	> Когда веруешь, аргумент не нужны. Согласен. Они аргументацию не воспринимают, даже если им её ужё разжёванную до мелочей прямо в рот запихать. Список тот появился не просто так, а потому, что один раз прописал, и можно оставлять ссылочку, не утруждая себя по-новой строчить одно и то же. Флеймы эти пошли массово году эдак в 2014м, и где-то спустя год всем опостылели в конец, потому что каждый раз одно и то же: ты объясняешь-объясняешь, что и как, но что бы ни было сказано в конце ланнартский фанат заявляет, что не было технической аргументации, что оппонент ретроград и закрыт для нового... Ну в общем, заявляет, что все Дартаньяны, а он - ... Вот тогда была найдена статья и сделана калька. Но напрасно. Они и её не читают тоже. :)
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	152. "Релиз systemd 233"	–2 +/–
	Сообщение от Аноним (??) on 03-Мрт-17, 11:12
	А ты сам её читал? В доказательстве 1.1 он опровергает утверждение "компоненты Systemd имеют хорошо описанные интерфейсы" утверждением "интерфейсы нестабильны". Это не опровержение! В доказательстве 1.2 он говорит что должно/не должно systemd на основании того, чем является/не является ядро. Это доказательство из серии "в огороде бузина, в Киеве дядька." Доказательство 4.1: он признаёт, что файлы скриптов systemd проще, чем для sysvinit, соглашаясь с исходным утверждением. Затем начинает сравнивать сложность программного кода systemd и sysvinit (не видя самого кода) и, на основании того, что скрипты проще, делает вывод что systemd сложнее. Ты приводишь это как доказательство, означает ли это, что ты с этим согласен? Отдельный камень в сторону перевода. Переводчик бестолковый и сам это признаёт. "binary file" = бинарник "Socket activation" = сокетная активация "Post" = пост Что это за бестолочь? Чтобы переводить нужно владеть родным языком лучше, чем иностранным. А чтобы переводить техническую литературу нужно знать технический английский. Очевидно, что переводчик им не владеет.
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	160. "Релиз systemd 233"	+/–
	Сообщение от freehck (ok) on 03-Мрт-17, 13:43
	> В доказательстве 1.1 он опровергает утверждение "компоненты Systemd имеют хорошо описанные > интерфейсы" утверждением "интерфейсы нестабильны". Это не опровержение! >> #1.1 "Компоненты Systemd имеют хорошо описанные интерфейсы, и поэтому вы можете просто заменить части, которые вам не нравятся" Суть-то Вы уловили, только аргумент против несколько другого утверждения. > В доказательстве 1.2 он говорит что должно/не должно systemd на основании того, > чем является/не является ядро. Это доказательство из серии "в огороде бузина, > в Киеве дядька." "Следует ли systemd быть монолитным или нет - абсолютно никак не относится к ядру Linux". Я было подумал, что Вы читаете между строк, но вдруг понял, что строка-то всего одна... > Доказательство 4.1: он признаёт, что файлы скриптов systemd проще, > чем для sysvinit, соглашаясь с исходным утверждением. Вранёёооо: >> #4.1: "Unit-файлы уменьшают сложность" >> >> Хотя unit-файлы действительно выглядят проще init-скриптов и могут >> уменьшить сложность определяемых сервисов, они ни уменьшают сложность >> системы инициализации, ни уменьшают сложность поиска ошибок в системе >> инициализации, когда она ведёт себя не правильно Нифига себе "соглашается с исходным утверждением", а? :) > Затем начинает сравнивать сложность программного кода systemd и > sysvinit (не видя самого кода) и, на основании того, что скрипты > проще, делает вывод что systemd сложнее. Ну офигеть. То есть если sysvinit проще systemd, из этого не следует, что systemd сложнее sysvinit?
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

	163. "Релиз systemd 233"	–4 +/–
	Сообщение от Аноним (??) on 03-Мрт-17, 13:58
	Вопрос: действительно ли unit-файлы проще init-скриптов? Ответ: unit-файлы действительно проще init-скриптов Абсолютное, полное согласие. > Нифига себе "соглашается с исходным утверждением", а? :) А вот после этого Остапа понесло и он начал сравнивать исходный код systemd, написанный на Си, с shell-скриптами. В следующих двух вопросах он подробно расписывает почему поиск ошибок и отладка программ на Си сложнее, чем написание shell-скрипта. > То есть если sysvinit проще systemd, из этого не следует, что systemd сложнее sysvinit Если скрипт для sysvinit проще исходного кода systemd, из этого совсем не следует, что systemd сложнее sysvinit. Я думал, вы это понимаете и без моих объяснений...
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	165. "Релиз systemd 233"	–1 +/–
	Сообщение от Аноним (??) on 03-Мрт-17, 14:15
	Q 1.1: Компоненты Systemd имеют хорошо описанные интерфейсы, и поэтому вы можете просто заменить части, которые вам не нравятся A: Это рассуждение ошибочно из-за одного упущения. Не все его интерфейсы стабильны Стоп игра! Речь в вопросе шла о документированности, а не о стабильности. Ответ не по теме вопроса. Q 1.2: Ядро Linux монолитное, поэтому это нормально, что systemd монолитен. A: Следует ли systemd быть монолитным или нет - абсолютно никак не относится к ядру Linux. Вопрос был в том насколько нормально что systemd монолитен, ответ - это никак не относится к ядру. Да, не относится, но где ответ на вопрос? Q 2: Многие используют systemd, значит ты тоже должен A: Классический пример ошибки "большинство не может ошибаться". Ошибаться в чём? Из того, что systemd использует большинство следует лишь то, что для большинства он более удобен, чем что-то другое, а значит он с большой вероятностью (пропорциональной доле systemd на рынке) будет самым удобным решением и для вас. Q 2.1, 3 -- болтология Q 4: Unit-файлы лучше, чем shell-скрипты A: Это ошибочное обобщение (почему?). Чем меньше кода - тем лучше (общеизвестная истина), но есть важные детали (детали есть всегда; какие именно?), на которые часто смотрят сквозь пальцы. Обвинить в неведении, но не сказать в чём оно заключается. Затем "заболтать" тему. Q 4.1: Unit-файлы уменьшают сложность Расписал выше Дальше продолжать? Покажи где он ответил по теме, внятно и содержательно?
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	155. "Релиз systemd 233"	+2 +/–
	Сообщение от Аноним (??) on 03-Мрт-17, 11:54
	В моём предыдущем коменте уровнем выше был только сарказм и ничего более :-) Статью естесственно прочитал целиком, очень познавательно, спасибо!
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	157. "Релиз systemd 233"	+4 +/–
	Сообщение от Аноним (??) on 03-Мрт-17, 11:59
	PS: Я просто попытался изобразить текст так как бы его написали поклонники поттеринга. Видимо получилось :) А сам я давно devuan юзаю, на локалхосте и на серверах
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	147. "Релиз systemd 233"	–1 +/–
	Сообщение от виндотролль (ok) on 03-Мрт-17, 10:08
	та статья — это рационализация точки зрения "системд плохой". Я с некоторыми пунктами согласен. Но в целом со статьей — не до конца. Например, аргумент о сложности. Дескать, системд 250,000 строк на си, а все скрипты в дебиане — 10,000 строк. Но 1) Баш гораздо более высокоуровневый — 10,000 на баше потребуют гораздо больше на си 2) почему бы к 10,000 не добавить количество строк си в исходных кодах баша?
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	151. "Релиз systemd 233"	+/–
	Сообщение от Andrey Mitrofanov on 03-Мрт-17, 10:48
	> та статья — это рационализация точки зрения "системд плохой". > Я с некоторыми пунктами согласен. Но в целом со статьей — не > до конца. > Например, аргумент о сложности. Дескать, системд 250,000 строк на си, а все > скрипты в дебиане — 10,000 строк. > Но > 1) Баш гораздо более высокоуровневый — 10,000 на баше потребуют гораздо больше > на си Дети! Сегодня мы будем играть в Угадайку!! А угадайте, кто с кем соревнуется, кто кого обгоняет и назовите имена участникао по... числу строк кода на Си в проектах: |    | Lang. | Code    | Comment | Comm.% | Blank  | Total   | Lang. % | | #1 | C     | 107,704 | 22,942  |  17.6% | 22,910 | 153,556 |   64.1% | | #2 | C     | 122,257 | 5,332   |   4.2% | 44,335 | 171,924 |   71.8% | | #3 | C     | 270,920 | 31,560  |  10.4% | 84,998 | 387,478 |   82.8% | | #4 | C     | 330,154 | 84,492  |  20.4% | 65,991 | 480,637 |   22.4% | | #5 | C     | 511,630 | 150,702 |  22.8% | 94,358 | 756,690 |   32.5% | > 2) почему бы к 10,000 не добавить количество строк си в исходных > кодах баша? Да! Престо, какой из коннурсантов ##1--5 выше -- bash, а какой == твой разжиревший фетиш. Или б*****о.
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	153. "Релиз systemd 233"	+/–
	Сообщение от виндотролль (ok) on 03-Мрт-17, 11:23
	Дядя, а без кривляний умеете?
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	154. "Релиз systemd 233"	–2 +/–
	Сообщение от Andrey Mitrofanov on 03-Мрт-17, 11:26
	> Дядя, а без кривляний умеете? Бала-бол.
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	156. "Релиз systemd 233"	+/–
	Сообщение от виндотролль (ok) on 03-Мрт-17, 11:59
	О нет! Дядя, видимо, mentally challenged. Высказывать свою точку зрения, приводя аргументы, не умеет. Вопросы читать не умеет. Серьезно, сложно сказать "я считаю, ты не прав, потому что баш это 100к, а системд, скажем — 500"? Даже текста надо меньше. Я бы, конечно, ответил, что в системд ты посчитал logind, udev, localectl, journalctl, и уж если считать, то надо добавлять к башу аналоги. А более того, порядок величин тот же. Разница между 100к и 200к не такая уж большая
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	158. "экзамен окончен. вы не умете считать статистики."	–2 +/–
	Сообщение от Andrey Mitrofanov on 03-Мрт-17, 13:01
	>[оверквотинг удален] >> Я с некоторыми пунктами согласен. Но в целом со статьей — не >> до конца. >> Например, аргумент о сложности. Дескать, системд 250,000 строк на си, а все >> скрипты в дебиане — 10,000 строк. >> Но >> 1) Баш гораздо более высокоуровневый — 10,000 на баше потребуют гораздо больше >> на си > Дети! Сегодня мы будем играть в Угадайку!! А угадайте, кто с кем > соревнуется, кто кого обгоняет и назовите имена участникао по... числу строк > кода на Си в проектах: Ответы   + На "5 с плюсом": https://www.opennet.ru/openforum/vsluhforumID3/107695.html#47 |              | Total C | C Code  | Си, % | Comment | Cmt.% | Blank  |  Bl.% | | GNU Bash     | 158,949 | 111,837 | 64.7% | 23,584  | 17.4% | 23,528 |   21% | | Nginx        | 178,751 | 127,242 | 71.7% | 5,407   |  4.1% | 46,102 | 36.2% | | Systemd      | 418,943 | 293,497 | 82.7% | 33,916  | 10.4% | 91,530 | 31.1% | | GNU Emacs    | 484,528 | 332,432 | 22.7% | 85,545  | 20.5% | 66,551 |   20% | | Apache HTTPD | 767,236 | 519,865 | 32.5% | 151,975 | 22.6% | 95,396 | 18.3% | (убрал Lang, добавил Bl.%, переместил Total "вперёд"; переименовал Total => Total-C; обновил чёрноутковскими _сегодняшнимим_ данными.)   + "Коммерсы"/индустриальные программёры (№№2,3) налегают на пустые строки и недовкладывают комментариев по ср.с "пр." конкурсантами. Совпадение, наверное, выборка мала. >> 2) почему бы к 10,000 не добавить количество строк си в исходных >> кодах баша? > Да! Престо, какой > твой разжиревший фетиш. >б*****Л.
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	166. "Релиз systemd 233"	+1 +/–
	Сообщение от freehck (ok) on 03-Мрт-17, 14:39
	> Я с некоторыми пунктами согласен. Но в целом со статьей — не до конца. > Например, аргумент о сложности. Дескать, системд 250,000 строк на си, а все скрипты в дебиане — 10,000 строк. Именно. Даже если взять sysvinit и посчитать вместе со скриптами запуска, разница получается аж на порядок. > 1) Баш гораздо более высокоуровневый — 10,000 на баше потребуют гораздо больше на си > 2) почему бы к 10,000 не добавить количество строк си в исходных кодах баша? А почему бы Вам тогда не прибавить к systemd количество строк в исходниках gcc? Давайте тогда ещё вспомним, что sysvinit позволяет писать не только на bash, но вообще на любых скриптовых языках - давайте и количество строк кода в их интерпретаторах посчитаем? И скрипты на bash (вот ведь неожиданность) дёргают самые разные утилиты, может нам и их посчитать? Добавлять удобно - чем больше добавляем, тем меньше относительная разница между проектами. А почему бы не поступить наоборот? Давайте Вы вычтете содержимое unit-файлов, а мы - код shell-скриптов. Не будет ли это сравнение более честным? Но тогда разница будет далеко не на один порядок, вот в чём беда. Суть же сравнения в том, что количество строк в проекте - это количество мест, где можно совершить ошибку. И чем меньше строк - тем меньше ошибок. Для того DSL и существуют: чтобы уменьшать их количество.
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	168. "Релиз systemd 233"	–3 +/–
	Сообщение от Аноним (??) on 03-Мрт-17, 14:46
	Ты в курсе, что сложную задачу делят на части, каждую из которых решают разные люди? Программисты пишут систему инициализации (СИ), администраторы пишут скрипты для СИ. Ты пытаешься складывать-вычитать количество строк исходного кода СИ с количеством строк в скриптах - какой в этом смысл? Суммарная сложность системы остаётся постоянной, но мы можем изменять сложность отдельных частей. В systemd посчитали, что нужно уменьшить сложность скриптов, увеличив сложность СИ. И то, что systemd стал популярным означает, что это решение было верным.
	Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

	169. "Релиз systemd 233"	+1 +/–
	Сообщение от freehck (ok) on 03-Мрт-17, 15:06
	> Ты пытаешься складывать-вычитать количество строк исходного кода СИ с количеством строк > в скриптах - какой в этом смысл? Смысл - в последнем абзаце. "количество строк в проекте - это количество мест, где можно совершить ошибку. И чем меньше строк - тем меньше ошибок"
	Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

	173. "Релиз systemd 233"	+/–
	Сообщение от Аноним (??) on 03-Мрт-17, 15:17
	Что ж, никто не мешает создать ещё одну систему инициализации, нацеленную на уменьшение суммарного количества строк в исходном коде и скриптах. У меня есть сомнения, что эта идея станет популярной, но кто знает...
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

	174. "Релиз systemd 233"	–2 +/–
	Сообщение от Аноним (??) on 03-Мрт-17, 15:29
	> чем меньше строк - тем меньше ошибок Нет. Чем меньше строк, тем меньше мест где можно допустить ошибку, но это не означает что они были допущены и не были исправлены. Посмотри на мишку Вонни, он в каждом слове по несколько ошибок делает. А Лев Толстой написал толстенную книжку и почти не накосячил.
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

	177. "Релиз systemd 233"	+/–
	Сообщение от Аноним (??) on 03-Мрт-17, 16:56
	> Посмотри на мишку Вонни, он в каждом слове по несколько ошибок делает. > А Лев Толстой написал толстенную книжку и почти не накосячил. проблемы начались, когда мишки Вонни на "Войну и мир" замахнулся
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	170. "Релиз systemd 233"	+/–
	Сообщение от виндотролль (ok) on 03-Мрт-17, 15:13
	Баш я прибавил, т.к. скрипты пишутся на баше. Я апеллирую к утверждению «системд имеет много строк кода на си. Чем больше строк кода в процессе инициализации, тем он сложнее и ненадежнее». Но в случае с sysvinit, bash является частью системы инициализации. Потому надо брать исходники sysvinit, исходники bash и сравнивать их. Потом, systemd имеет продвинутую систему журналирования (весьма неплохую, кстати. Я люблю плейтекст, но переход на бинарный формат для увеличения производительности записи и поиска — это правильный шаг). Т.е. сравнение уже неравное получается. Я хочу прояснить: с теплотой вспоминаю времена, когда стартовал демоны, добавляя их в deamons array в rc.conf. Но это решение для одной машины. И потом и хорошо помню, как для ускорения процесса загрузки предлагалось _экспериментировать_ с запуском в бекграунде. Т.е. процесс не автоматизируемый. Системд в этом смысле — это гораздо больше, чем система инициализации. Это инициатива, призванная навести порядок в запускаемых демонах, ведь необходимо явно задекларировать зависимости и т.д.. Это как сравнивать make install с apt-get install. make install проще дебажить, кол-во строк кода на си меньше, можно сделать все, что угодно, система гибкая, простая, каждая бабушка понимает... А с этим apt я не могу легко установить свою программу на любую систему, приходится возиться с dpkg, читать плохую документацию и т.д..
	Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

	184. "Релиз systemd 233"	+4 +/–
	Сообщение от freehck (ok) on 03-Мрт-17, 20:02
	> Баш я прибавил, т.к. скрипты пишутся на баше. Я апеллирую к утверждению > «системд имеет много строк кода на си. Чем больше строк кода > в процессе инициализации, тем он сложнее и ненадежнее». > > Но в случае с sysvinit, bash является частью системы инициализации. Потому надо > брать исходники sysvinit, исходники bash и сравнивать их. Вообще-то bash частью sysvinit не является. То, что после запуска init запускает скрипт, который производит дальнейшую инициализацию ОС - не делает этот скрипт частью init-а. Если включать в подсчёт сам скрипт, то есть нюанс: в разных осях sysvinit запускает разные скрипты. Где-то они на shell, где-то на python. Из shell-ов это может быть bash, может быть dash, может быть что-либо ещё. Почему же именно bash? А знаете что ещё? Вместо скриптов для запуска в /etc/init.d могут быть бинари. На протяжении десятков лет можно было использовать бинари вместо скриптов. Главное, чтобы они принимали аргументы start, stop, restart, reload... Что ж нам теперь, gcc в подсчёт включать? И вот при этом Вы предлагаете включить в подсчёт строк кода не только скрипты, но и один из интерпретаторов? У меня только один вопрос остаётся тогда, который я уже задал: почему Вы не хотите присовокупить сюда ещё код всех бинарных утилит, которые дёргаются этими скриптами? -- Ну хорошо. Не смотря на то, что bash не является частью sysvinit, давайте сложим. Вот тут рядом пост Митрофанова, по которому получается, что даже если мы сложим, всё равно systemd в проигрыше. Правда, уже не на порядок, конечо. Если Вам с этого легче - да ради бога. Может быть теперь это для Вас "незначительная разница", но имейте в виду, что эти 100к строчек отлаживали последние 30 лет или около того.  Ваша systemd существует в 5 раз меньше, а весит в 3 раза больше. > Потом, systemd имеет продвинутую систему журналирования (весьма неплохую, кстати. Я люблю > плейтекст, но переход на бинарный формат для увеличения производительности записи и > поиска — это правильный шаг). Т.е. сравнение уже неравное получается. Нет, не правильный. Раз. (см. #10 - про бинарные логи) https://www.opennet.ru/base/sys/systemd_myth.txt.html Два. (укороченный до сути вариант предудущего) https://www.opennet.ru/openforum/vsluhforumID3/110582.html#161 > Я хочу прояснить: с теплотой вспоминаю времена, когда стартовал демоны, добавляя их > в deamons array в rc.conf. > Но это решение для одной машины. И потом и хорошо помню, как для > ускорения процесса загрузки предлагалось _экспериментировать_ с > запуском в бекграунде.  Т.е. процесс не автоматизируемый. Да, я тоже с теплотой их вспоминаю, но ведь современный sysvinit уже давным-давно не такой. > Системд в этом смысле — это гораздо больше, чем система > инициализации. Это инициатива, призванная навести порядок в > запускаемых демонах, ведь необходимо явно задекларировать > зависимости и т.д.. Так ведь в том и дело, что эта инициатива в дебиановском sysvinit уже имелась на момент создания systemd. Ко скриптам инициализации были добавлены LSB-заголовки, в которых прописали зависимости. Sysvinit стартовал демоны параллельно и разруливал зависимости. https://wiki.debian.org/LSBInitScripts Обратите внимание: они были добавлены ещё в Lenny. А это, извините, 2009й. То есть за два года до появления Systemd. > Это как сравнивать make install с apt-get install. make install проще дебажить, > кол-во строк кода на си меньше, можно сделать все, что угодно, > система гибкая, простая, каждая бабушка понимает... > А с этим apt я не могу легко установить свою программу на > любую систему, приходится возиться с dpkg, читать плохую документацию и т.д.. Сравнение хорошее, за той лишь разницей, что APT решает реальную проблему: он разруливает процесс доставки и установки огромного количества пакетов. Make же этим не занимается. А вот systemd не решает никаких старых проблем, зато привносит море новых. Хотите пруфов, хотите? Их у меня много. Вся рассылка debian-russian, а ещё располагаю подборкой комментариев с opennet.
	Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

	188. "Релиз systemd 233"	+/–
	Сообщение от виндотролль (ok) on 03-Мрт-17, 22:46
	> Почему же именно bash? цепочки инита kernel -> (sysvinit -> bash + grep + ps + kill + ...) -> target binary kernel -> systemd -> target binary В первом случае может быть другой шел, да. Но не суть. Мне не понравился сам лишь подход, что в случае с sysvinit считаем строчки "юнит-файлов" (они же скрипты), а в случае с systemd — строчки системы инициализации. > эти 100к строчек отлаживали последние 30 лет или около того С таким подходом никогда нельзя разрабатывать что-то новое. Говорить, что системд плохая, потому что ее конкурент уже 30 лет работает — это, мне кажется, неконструктивно. Конструктивно говорить, что в системд есть баги (и это правда), говорить какие именно, и тогда их будут фиксить. > Раз. (см. #10 - про бинарные логи) все зависит от реализации. Современные информационные системы уже давно обходят проблему фейла физического носителя или бага в программе иначе — бекапы, copy on write и т.д.. На самом деле сильных аргументов у меня нету. Я не очень понимаю проблему. Все приложения, с которыми я сталкивался, и для которым критично логирование, имеют собственные системы логирования (чаще, на удаленный сервер). Но я по своему опыту знаю, что лет 10 назад было принято логи писать в структурированное хранилище (БД), потому что тяжело было что-то сделать с 20 гб плейн текст логов. И это очень похоже на жоурналд. Сейчас — время облаков, все, обычно, пишется в системы хранения логов, например, на основе эластиксерч. И там тоже структурированный формат. Есть поле месседж, где фритекст, есть поле хост, есть поле ип, есть поле дата, и т.д.. И эти логи тоже нельзя прочитать с помощью вима. И это тоже очень похоже на жоурналд. Но, повторюсь, я, возможно, далек от проблемы. > Так ведь в том и дело, что эта инициатива в дебиановском sysvinit уже имелась на момент создания systemd. Ко скриптам инициализации были добавлены LSB-заголовки, в которых прописали зависимости. Sysvinit стартовал демоны параллельно и разруливал зависимости. Вот об этом я не знал. Положительные моменты системд 1) я могу написать сервис, который перезапустит бинарь, если тот упадет, и мне не придется для этого использовать ps, grep, kill, rm myapp.pid и т.д. 2) я знаю, что мой сервис стартонет тогда, когда придет время Если другие системы это позволяют, ну что ж, жаль, что большинству о них не известно. Быть может мы бы имели систему инициализации без недостатков системд. > Хотите пруфов, хотите? Их у меня много. Вся рассылка debian-russian, а ещё располагаю подборкой комментариев с opennet. Да я и сам могу подбросить. Иногда проще написать while true; do ./mydaemon; done чем разбираться, почему с системд скрипт вообще не стартует. Или почему, при умирании не отрабатывает очистка каких-нибудь ресурсов. Или... Да много я провел времени, чертыхаясь. То диски не отмонтируются. То пользовательская сессия на стартует. За это время можно было бы сотни две баш скриптов написать. Я — вовсе на фанат системд. И использую его лишь потому, что он поставляется по умолчанию на моем дистрибутиве. Напоминаю, что я лишь высказал критику к статье о мифах о системд — не всегда весомые аргументы. Ну и я пытаюсь видеть удачные решения в системд.
	Ответить | Правка | ^ к родителю #184 | Наверх | Cообщить модератору

	190. "Релиз systemd 233"	+/–
	Сообщение от Vkni (ok) on 04-Мрт-17, 07:31
	> В первом случае может быть другой шел, да. Ну это, вообще говоря, признак хорошей архитектуры - возможность относительно лёгкой модификации подручными средствами. Всё-таки переписать 10 тыс строк скриптов задача подъёмная, а переписать 400k строк на Цэ - нет. > Напоминаю, что я лишь высказал критику к статье о мифах о системд > — не всегда весомые аргументы. Ну и я пытаюсь видеть удачные > решения в системд. Это сродни поиску алмазов в известной субстанции. Код subj'а тут уже приводили - это эталон г-кодерства.
	Ответить | Правка | ^ к родителю #188 | Наверх | Cообщить модератору

	191. "Релиз systemd 233"	+/–
	Сообщение от виндотролль (ok) on 04-Мрт-17, 13:40
	> Ну это, вообще говоря, признак хорошей архитектуры - возможность относительно лёгкой модификации подручными средствами. подручными средствами — это уже не важно, к архитектуре отношения не имеет. А возможность использования другого шелла — это прекрасно, это говорит о правильной абстракции. Но и в системд есть возможность хоть баш из юнита вызвать, хоть, питон. Системд предоставляет более высокоуровневый интерфейс. У этого есть и плюсы, и минусы. 100500 раз уже обсуждалось, не хочу повторять очевидные вещи. Я могу привести признак плохой архитектуры sysvinit — *.pid файлы. Системд они не требуются, потому что он знает, какие процессы породил. А в sysvinit приходилось (может уже нет, вон товарищ выше про зависимости в sysvinit рассказал) сохранять pid на диск, что приводило к неконсистентности: процесс мог давно умереть, а pid файл остается. Но еще раз, я не защищаю systemd per se. Я призываю к его конструктивной критике. Авторы systemd заинтересованы в его стабильности, пожалуй, даже больше, чем пользователи. Хейтерство — это ну просто неконструктивно, если речь идет об опенсорс. > Это сродни поиску алмазов в известной субстанции. Код subj'а тут уже приводили > - это эталон г-кодерства. К сожалению, не видел, но, пожалуй, могу поверить. Такие большие проекты в такие короткие сроки часто получаются не самого высокого качества. Но, с другой стороны, если б все было совсем-совсем плохо, то вряд ли бы проект дожил до 233 версии.
	Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

	214. "Релиз systemd 233"	+/–
	Сообщение от Vkni (ok) on 04-Мрт-17, 22:49
	> подручными средствами — это уже не важно, к архитектуре отношения не имеет. > А возможность использования другого шелла — это прекрасно, это говорит о > правильной абстракции. Но и в системд есть возможность хоть баш из > юнита вызвать, хоть, питон. И то, слава богу. Но вы не учитываете возможности полной перестройки системы на совершенно другом скриптовом языке. Т.е. это бы означало полное переписывание unit файлов на другой DSL. В sysVinit'е абсолютно другой уровень гибкостиё > Авторы systemd заинтересованы в его стабильности, пожалуй, даже больше, чем пользователи. В это утверждение невозможно поверить. Я смотрел код systemd, неоднократно его тут цитировал. Так люди, мало мальски заинтересованные в стабильности и обладающие квалификацией хотя бы на уровне табуретки, не пишут.
	Ответить | Правка | ^ к родителю #191 | Наверх | Cообщить модератору

	218. "Релиз systemd 233"	+/–
	Сообщение от виндотролль (ok) on 04-Мрт-17, 23:35
	> В это утверждение невозможно поверить. Это было предположение. Беру слова обратно :)
	Ответить | Правка | ^ к родителю #214 | Наверх | Cообщить модератору

	199. "Релиз systemd 233"	+2 +/–
	Сообщение от freehck (ok) on 04-Мрт-17, 18:17
	> Мне не понравился сам лишь подход, что в случае с sysvinit считаем > строчки "юнит-файлов" (они же скрипты), а в случае с systemd — > строчки системы инициализации. Хм. Знаете, у меня раж спал, я подумал, и понял, что таки да. Корректности ради код интерпретатора, возможно, стоит включить, потому как systemd инкапсулирует в себя код обработки unit-файлов. То, что интерпретатор и скрипты возможно заменить - это уже камень в сторону модульности. >> эти 100к строчек отлаживали последние 30 лет или около того > С таким подходом никогда нельзя разрабатывать что-то новое. Я не совсем это имел в виду. Речь, скорее, о надёжности инструмета. Инструмент, отлаженный за несколько десятилетий, вызывает больше доверия. А по поводу разработки нового, то я думаю так. Единственное оправдание разработки нового, это наличие задач, не решаемых старым инструментом. > Конструктивно говорить, что в системд есть баги (и это правда), > говорить какие именно, и тогда их будут фиксить. Так ведь и говорят. Но фиксится далеко не всё. Разработчики уделяют куда больше внимания новым фичам, нежели исправлению существующих дефектов. >> Раз. (см. #10 - про бинарные логи) > все зависит от реализации. Современные информационные системы уже давно обходят проблему > фейла физического носителя или бага в программе иначе — бекапы, copy > on write и т.д.. Да, на самом деле я тут солидарен с Вами. В самой концепции бинарного лога нет ничего плохого. Бинарный лог может позволить хранить много дополнительной информации, которая ускорит поиск по логу и его анализ. Собственно, речь в статье как раз о том и ведётся. Проблема в реализации бинарного лога в systemd: она не отказоустойчива. Если лог-файл был повреждён, то восстановить его невозможно. Таким образом, если у винчестер начал сбоить, то всё, логи Вы безвозвратно теряете, что может сильно помешать в диагностике неполадок. Справедливо замечается, что мета-информацию (те же индексы и т.п.)  можно было бы хранить отдельно от plain-text лога, что повысило бы отказоустойчивость journald. > Все приложения, с которыми я сталкивался, и для которым критично логирование, имеют > собственные системы логирования (чаще, на удаленный сервер). Но я по своему > опыту знаю, что лет 10 назад было принято логи писать в > структурированное хранилище (БД), потому что тяжело было что-то сделать с 20 > гб плейн текст логов. И это очень похоже на жоурналд. Двадцатигиговый plain-text лог редко встречается на практике. Это, позвольте сказать, граничные случаи. Для граничных случаев используются специализированные решения, что само собой разумеется. У нас в компании тоже есть для таких вот задач решения. Например есть сервис отчётов, который сохраняет всю мета-информацию о http(s)-запросах в режиме реального времени и позволяет быстро по ней произвести поиск, когда понадобится. Но это не то, чтобы лог. Это всё-таки база для весьма специфичных нужд (нужд инженеров-безопасников). > Положительные моменты системд > 1) я могу написать сервис, который перезапустит бинарь, если тот упадет, и > мне не придется для этого использовать ps, grep, kill, rm myapp.pid > и т.д. А, много раз слышал, как systemd-шники гордятся своим watchdog-ом. Но позвольте заметить, что как минимум ещё в начале нулевых Бернштейн написал daemontools - набор утилит, которые именно тем и занимаются, что следят за тем, чтобы сервисы крутились. Уже 15 лет используем в нашей конторе для критичных мест. > 2) я знаю, что мой сервис стартонет тогда, когда придет время Я не понял, о чём Вы. > Если другие системы это позволяют, ну что ж, жаль, что большинству о > них не известно. Быть может мы бы имели систему инициализации без > недостатков системд. Да, это по-видимому основная проблема GNU/Linux: наличие огромного выбора. Большинство плавает среди этого выбора и не знает, куда податься. В systemd, наверное, легче: ты выбираешь его, и за тебя уже выбрали всё, и отступить ни на шаг от этого выбора уже не удастся. Просто это совсем не тот GNU/Linux, который мы когда-то полюбили. Это GNU/Linux, с которым мы уже ничего не сможем сделать сами, в котором мы ничего не сможем изменить. Мне такой GNU/Linux нафиг не нужен. >> Хотите пруфов, хотите? Их у меня много. Вся рассылка debian-russian, а ещё располагаю подборкой комментариев с opennet. > Да я и сам могу подбросить. Иногда проще написать while true; do > ./mydaemon; done чем разбираться, почему с системд скрипт вообще не стартует. Во-во. Именно для того, чтобы не писать так, я использую djb daemontools. Да вот даже прямо сейчас на моей машине крутится один проприетарный игровой сервер, запущенный именно таким образом. > Я — вовсе на фанат системд. И использую его лишь потому, что > он поставляется по умолчанию на моем дистрибутиве. Соболезную. > Напоминаю, что я лишь высказал критику к статье о мифах о системд > — не всегда весомые аргументы. Ну и я пытаюсь видеть удачные > решения в системд. Да, возможно, надо бы слегка освежить статью. Я благодарен Вам за свежий взгляд. Подумаю, что можно сделать для её актуализации.
	Ответить | Правка | ^ к родителю #188 | Наверх | Cообщить модератору

	189. "Релиз systemd 233"	+1 +/–
	Сообщение от Vkni (ok) on 04-Мрт-17, 07:27
	> Может быть теперь это для Вас "незначительная разница", но имейте в виду, > что эти 100к строчек отлаживали последние 30 лет или около того. >  Ваша systemd существует в 5 раз меньше, а весит в > 3 раза больше. Я бы не сказал, что за bash уж так нужно биться. Язык shell серьёзно устарел, но обладает рядом уникальных фич, ака ленивость + мегапараллелизуемость. SysVinit как раз хорош тем, что позволяет заменить bash на любой другой скриптовый язык соответсвующей мощности, скажем, make. Можно, в принципе, сделать что-то более-менее современное на базе Хаскелля или Ocaml'а (язык, разумеется, не в прямую использовать).
	Ответить | Правка | ^ к родителю #184 | Наверх | Cообщить модератору

	200. "Релиз systemd 233"	+/–
	Сообщение от freehck (ok) on 04-Мрт-17, 18:50
	>> Может быть теперь это для Вас "незначительная разница", но имейте в виду, >> что эти 100к строчек отлаживали последние 30 лет или около того. >>  Ваша systemd существует в 5 раз меньше, а весит в >> 3 раза больше. > Я бы не сказал, что за bash уж так нужно биться. Язык > shell серьёзно устарел, но обладает рядом уникальных фич, ака ленивость + > мегапараллелизуемость. Согласен. Лично мне больше нравится zsh. Там реально меньше шансов ошибиться. Но чтобы серьёзно что-либо утверждать по данному вопросу, мне стоило бы сначала изучить больше шеллов. Я сейчас, увы только три знаю. > Можно, в принципе, сделать что-то > более-менее современное на базе Хаскелля или Ocaml'а (язык, разумеется, не в > прямую использовать). По-моему мы уже это где-то обсуждали, и не пришли к единому мнению, что же мы хотим привнести в новый язык. Я не очень понимаю, где же нам пригодится строгая типизация в замене shell-а. На Ocaml было бы очень просто сделать любой DSL (ocamlyacc/menhir + ocamllex в помощь). Но разве что для прототипа. У Ocaml будет слишком большой рантайм, чтобы эффективно форкаться.
	Ответить | Правка | ^ к родителю #189 | Наверх | Cообщить модератору

	213. "Релиз systemd 233"	+/–
	Сообщение от Vkni (ok) on 04-Мрт-17, 22:42
	> На Ocaml было бы очень просто сделать любой DSL (ocamlyacc/menhir + ocamllex в помощь). Но разве что для прототипа. У Ocaml будет слишком большой рантайм, чтобы эффективно форкаться. Я имел ввиду, что мы берём язык, а не реализацию, из которого уже делаем другой язык. Т.е. про runtime на данном этапе речи нет. > Я не очень понимаю, где же нам пригодится строгая типизация в замене shell-а. Дополнительные проверки - shell часто используется для запуска тяжёлых задач, работающих сутки. Если нет хорошей статической типизации, приходится тестировать все ветки исполнения, что может растянуться на неделю, если не писать обвязки-заглушки.
	Ответить | Правка | ^ к родителю #200 | Наверх | Cообщить модератору

	71. "Релиз systemd 233"	–2 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 19:31
	>>Он просто работает. Причем и на машинах с субжом. Разумеется; я сейчас с такой машины и пишу. Я имел в виду: не собираются ли разработчики, не дай бог, его забросить.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	146. "Релиз systemd 233"	+/–
	Сообщение от Stanislav (??) on 03-Мрт-17, 10:05
	Для таких случаев всегда можно взять что-нибудь другое, начиная с upstart, проходя через runit, заканчивая скриптом на шелле.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	51. "Релиз systemd 233"	+1 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 18:33
	А кстати, да, пусть свой systemd-kerneld пилит. Торвальдс, всё равно, его патчи в ваниллу не пустит. Так что, пусть пилит в одно рыло.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	68. "Релиз systemd 233"	+/–
	Сообщение от Andrey Mitrofanov on 02-Мрт-17, 19:27
	> А кстати, да, пусть свой systemd-kerneld пилит. Торвальдс, всё равно, его патчи > в ваниллу не пустит. Так что, пусть пилит в одно рыло. Кстати о пересипективах s-d! Линус в '91ом на своей 386sx запилил терминалку -- в '2014-ом случился ibm с  "перспективами" на миллиардом. В 2010ом ("Sievers started the project to develop systemd in"~~WP:s-d) оно началось с "миллиардами" персперкив Рх -- ...значит, году, эдак, к ....  ... ...... 2033-ему Ленарт допишет его до ядра терминалки на 386sx! ...в комнате студ.общаги?! ....в маленькой европейчкой стране.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	115. "Релиз systemd 233"	+1 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 23:45
	> А кстати, да, пусть свой systemd-kerneld пилит. Торвальдс, всё равно, его патчи > в ваниллу не пустит. Так что, пусть пилит в одно рыло. Пустит, не пустит, какая разница. Ванильное ядро в любом случае - переусложенный блоб. Истинные юниксоиды уже давно планируют переписать его на баше, чтобы было гибко и прозрачно.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	195. "Релиз systemd 233"	+/–
	Сообщение от anomymous on 04-Мрт-17, 15:00
	> Истинные юниксоиды уже давно планируют переписать его на баше, чтобы было гибко > и прозрачно. Осторожно, среди хейтеров системд очень много фанатов микроядра.
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	144. "Релиз systemd 233"	+2 +/–
	Сообщение от Аноним (??) on 03-Мрт-17, 09:47
	> когда уже Поттеринг свое ядро запилит точно, и уйдёт на х..р из linux
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

29. "Релиз systemd 233"	+8 +/–
Сообщение от RobotsCantPoop on 02-Мрт-17, 16:09
"А сейчас мы попробуем со всей этой фигнёй взлететь"
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	31. "Релиз systemd 233"	+8 +/–
	Сообщение от Andrey Mitrofanov on 02-Мрт-17, 16:34
	> "А сейчас мы попробуем со всей этой фигнёй взлететь" =А сейчас вы всю эту фигню будете тестить=
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	76. "Релиз systemd 233"	–1 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 19:43
	Тестить? Это, пожалуйста, к команде ядра. Они умеют и делают, да
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	231. "Релиз systemd 233"	+/–
	Сообщение от Andrey Mitrofanov on 08-Мрт-17, 09:04
	>> "А сейчас мы попробуем со всей этой фигнёй взлететь" > =А сейчас вы всю эту фигню будете тестить= :( Debian - "задрав штаны бежать" https://piware.de/post/2017-02-25-test-systemd-pre-233/
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

34. "Релиз systemd 233"	+2 +/–
Сообщение от Аноним (??) on 02-Мрт-17, 17:05
Спасибо systemd и лично Леннарту Поттерингу. Без него я бы никогда не нашел в себе сил перейти на FreeBSD.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	35. "Релиз systemd 233"	+/–
	Сообщение от A.Stahl (ok) on 02-Мрт-17, 17:18
	Изен, залогинься:)
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	48. "Релиз systemd 233"	+/–
	Сообщение от chinarulezzz (ok) on 02-Мрт-17, 18:21
	Попробуй CRUX. Freebsd-like система портов, ядро собираешь по-своему.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	63. "Релиз systemd 233"	+/–
	Сообщение от Andrey Mitrofanov on 02-Мрт-17, 19:08
	> Попробуй CRUX. Freebsd-like система портов, ядро собираешь по-своему. На GuixSD же!  GNU!!  Бесплатный бонус: Они уже переписали pid(1) на LISP.  Спешите---
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	78. "Релиз systemd 233"	+/–
	Сообщение от Лиспоманьяк on 02-Мрт-17, 20:13
	А вот попрошу Вас уточнить какой именно ЛИСП, пожалуйста.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	136. "Релиз systemd 233"	+/–
	Сообщение от Andrey Mitrofanov on 03-Мрт-17, 08:50
	>какой именно ЛИСП Тот, который https://www.gnu.org/s/shepherd/ GNU Guile scheme.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	222. "Релиз systemd 233"	–1 +/–
	Сообщение от Аноним (??) on 05-Мрт-17, 18:02
	тогда уже гента или слака ;) ортодоксальнее и прозрачнее(да и легковеснее, тоже)некуда, ну акромя LFS, нарное(и всяких DSL, TinyCore, Puppy мутаций и тп).
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	224. "Релиз systemd 233"	+/–
	Сообщение от chinarulezzz (ok) on 05-Мрт-17, 21:10
	> тогда уже гента или слака ;) > ортодоксальнее и прозрачнее(да и легковеснее, тоже)некуда, ну акромя LFS, нарное(и всяких > DSL, TinyCore, Puppy мутаций и тп). Ты просто CRUX не пробовал. LFS > CRUX > Slackware > [всё остальное]
	Ответить | Правка | ^ к родителю #222 | Наверх | Cообщить модератору

38. "Релиз systemd 233"	+1 +/–
Сообщение от ram_scan on 02-Мрт-17, 17:31
А не проще было вместо этой херовой толпы фичей запилить в системды systemd-sysv-initd и решить головняки на корню ? Дарю идею.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

49. "Релиз systemd 233"	+4 +/–
Сообщение от Аноним (??) on 02-Мрт-17, 18:26
>новые опции монтирования в fstab Такой весь передовой systemd всё ещё использует такой архаизм как fstab? ;)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	89. "Релиз systemd 233"	+/–
	Сообщение от Аноним (??) on 02-Мрт-17, 21:32
	>>новые опции монтирования в fstab > Такой весь передовой systemd всё ещё использует такой архаизм как fstab? ;) Да, он разбивается на несколько целей монтирования, в результате у системных служб можно выстраивать зависимости. Например, если в fstab есть монтирование /home, создаётся цель var.mount. Если требуется зависимость от примонтированного /var, то в unit-файле пишется: After=var.mount Так создаются зависимости. Система крайне удобная по сравнению с SysV, где зависимости приходилось делать ручками и они были слишком сложными из-за отсутствия стандартных средств, которые сейчас предоставляет systemd.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	90. "Релиз systemd 233"	–1 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 21:34
	>>>новые опции монтирования в fstab >> Такой весь передовой systemd всё ещё использует такой архаизм как fstab? ;) > Например, если в fstab есть монтирование /home, создаётся цель var.mount. Опечатался, home.mount. var.mount - для /var
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	104. "Релиз systemd 233"	–2 +/–
	Сообщение от Михрютка (ok) on 02-Мрт-17, 23:07
	что вы рассказуете противно слушать. какие нафиг зависимости от примонтированного /var, когда у вас всех точек монтирования бут, рут и темп. вы когда мерждили статик бин и бин с юзером, всем так и рассказывали - ето анахронизьм и долой с парохода современности, с нынешними объемами саташечек ето неактуально. а тут вдруг - зависимости от примонтированного вар ах ах.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	116. "Релиз systemd 233"	–1 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 23:47
	> что вы рассказуете противно слушать. какие нафиг зависимости от примонтированного /var, Например, var-tmp.mount.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	120. "Релиз systemd 233"	+/–
	Сообщение от marios (ok) on 02-Мрт-17, 23:53
	Про встраиваемую технику слыхал? :)
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	133. "Релиз systemd 233"	–1 +/–
	Сообщение от Аноним (??) on 03-Мрт-17, 02:58
	А что, кто-то ставит Debian + systemd на встраиваемую технику? Каждой задаче - своё решение.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	183. "Релиз systemd 233"	–1 +/–
	Сообщение от Аноним (??) on 03-Мрт-17, 19:05
	> А что, кто-то ставит Debian + systemd на встраиваемую технику? Каждой задаче > - своё решение. Да, я занимаюсь такой разработкой в частности. Могу сказать, что systemd очень удобная система в таком случае, но есть ещё некоторые недостатки: система ещё недостаточно гибкая. Например, не позволяет назначить сервису пользователя из файла конфигурации сервиса. Либо жёстко прописывается в unit-файле, либо через шаблоны unit-файлов, что не всегда подходит, либо через костыль в виде su, куда можно передать переменные из файла окружения. Одно из преимуществ, полученных от systemd - скорость загрузки. По сравнению с платформой на базе SystemV скорость загрузки выросла в несколько раз за счёт параллельной загрузки сервисов и собственного порядка загрузки.
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	187. "Релиз systemd 233"	+/–
	Сообщение от Аноним (??) on 03-Мрт-17, 22:38
	Может быть у вас ещё и SSD, помимо сата? Это вам для размышлений над монтированием /var, /var/tmp и /home не в embedded.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

50. "Релиз systemd 233"	+2 +/–
Сообщение от Аноним (??) on 02-Мрт-17, 18:27
>Все поставляемые в составе systemd скрипты на языке Python Где-то я это уже видел.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	64. "Релиз systemd 233"	+/–
	Сообщение от proud_anon on 02-Мрт-17, 19:11
	Нет.. нет.. нет.. остановите землю! Этот *пип* *бип* Джамшут и изобретатель кубического колеса, он же как Мейзуллина и Пилонов в одном лице.Господь пошли ему долгие дни.. (годы нет нужды). Чтобы у него был полон дом устройств интернета-вещей с 200MHz и 32 Мб озу с установленными на них его же сыстемД
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	196. "Релиз systemd 233"	–3 +/–
	Сообщение от anomymous on 04-Мрт-17, 15:03
	640кб хватит всем? Вас жаба задушила поставить в ваш ембеддед 512М вместо 32М, доплатив аж целых 1$ (в случае очень крупного опта)? Ну и да - для этих вещей есть бизибокс.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	207. "Релиз systemd 233"	+/–
	Сообщение от . on 04-Мрт-17, 20:38
	Тэорэтик - в сад!
	Ответить | Правка | ^ к родителю #196 | Наверх | Cообщить модератору

	73. "Релиз systemd 233"	+/–
	Сообщение от Andrey Mitrofanov on 02-Мрт-17, 19:33
	>>Все поставляемые в составе systemd скрипты на языке Python > Где-то я это уже видел. В новости "Hg переходит на git".
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	208. "Релиз systemd 233"	+/–
	Сообщение от . on 04-Мрт-17, 20:39
	Андрейка, а ты злой :)
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	84. "Релиз systemd 233"	–1 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 21:11
	> Все поставляемые в составе systemd скрипты на языке Python Яву туды надо. Чтоб кроссплатформенно и с прицелом на захват винды (а потом и всего мира, чо уж там...).
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	118. "Релиз systemd 233"	+/–
	Сообщение от Аноним (??) on 02-Мрт-17, 23:50
	>> Все поставляемые в составе systemd скрипты на языке Python > Яву туды надо. Слишком юниксвейно.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	137. "Релиз systemd 233"	+/–
	Сообщение от Andrey Mitrofanov on 03-Мрт-17, 08:59
	>>> Все поставляемые в составе systemd скрипты >> Яву туды надо. > Слишком юниксвейно. Не ту яву. https://developers.redhat.com/blog/category/programming/dot-net/ . https://developers.redhat.com/blog/tag/dot-net/ . https://developers.redhat.com/blog/category/programming/c-sharp/ . https://developers.redhat.com/blog/tag/asp-net/ . https://developers.redhat.com/blog/tag/microsoft/
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

79. "Релиз systemd 233"	+2 +/–
Сообщение от Аноним (??) on 02-Мрт-17, 20:14
Общее количество опций и параметров - сколько там уже нулей?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

103. "Релиз systemd 233"	+/–
Сообщение от asand3r on 02-Мрт-17, 23:05
> В systemd-mount добавлена опция "--umount" для отмонтирования разделов; Простите, а раньше как нужно было ФС размонтировать?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	114. "Релиз systemd 233"	+2 +/–
	Сообщение от Ан (??) on 02-Мрт-17, 23:44
	systemctl mount systemd-mount --umount
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	119. "Релиз systemd 233"	–1 +/–
	Сообщение от Аноним (??) on 02-Мрт-17, 23:52
	> systemctl mount systemd-mount --umount Почти. systemctl stop blabla.mount
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

123. "Релиз systemd 233"	–3 +/–
Сообщение от Аноним (??) on 03-Мрт-17, 00:53
Когда-то был против, потому что нравился upstart (потому что без баша и декларативно и в дистрибе, на котором сижу). Потом всё решили за меня и пришлось скачать http://wiki.opennet.ru/Systemd_%D0%B4%D0%... и изучать. Какой же он крутой! Никакого bash-петушения, декларативное описание сервисов, drop-in конфигурации и т.д. Логи все на месте (не надо верещать, что в бинарном формате, всё равно даже текстовые смотрите с помощью отдельной утилиты). И всё это просто работает!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	128. "Релиз systemd 233"	+2 +/–
	Сообщение от Kroz (ok) on 03-Мрт-17, 01:29
	> Никакого bash-петушения, декларативное описание сервисов, > И всё это просто работает! Где-то я это уже слышал. Кто сказал Windows? Когда столкнетесь с не совсем стандартными зачами, вспомните и про "bash-петушения" и про "просто работает"...
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	162. "Релиз systemd 233"	+1 +/–
	Сообщение от freehck (ok) on 03-Мрт-17, 13:55
	> Когда столкнетесь с не совсем стандартными зачами, вспомните и про "bash-петушения" и > про "просто работает"... Не вспомнят. Они скажут начальству "это невозможно", начальство пожмёт плечами, и всё замнётся. Очень удобный инструмент для корпорастов: если явно не прописано, как с помощью инструмента сделать то-то, значит этого сделать нельзя. Если прописано, но не работает, как надо - значит багу разработчикам. Такой подход, правда, превращает сисадмина в обезьянку, бездумно жмущую на кнопки в определённой последовательности. Грустно, конечно, но зато посмотри, как они радуются!
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	234. "Релиз systemd 233"	+/–
	Сообщение от Аноним (??) on 07-Окт-17, 16:20
	> Такой подход, правда, превращает сисадмина в обезьянку, бездумно жмущую на кнопки в > определённой последовательности. А, собственно, вам не стыдно все еще считать админство рокетсайнс и безумным страстным творчеством? При наличии достаточных железных ресурсов все админство сводится к "убить по вотчдогу ноду, перезапустить".
	Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

	138. "Релиз systemd 233"	+2 +/–
	Сообщение от Andrey Mitrofanov on 03-Мрт-17, 09:02
	>Никакого bash-петушения, Позовите Гарета, Сару и Аврору  --  у нас жертва харасмента.
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	176. "Релиз systemd 233"	+/–
	Сообщение от Аноним (??) on 03-Мрт-17, 16:32
	Я стесняюсь спросить, если скрипты на баше - это харрасмент, то что же тогда конфиги sendmail?
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	179. "Релиз systemd 233"	+1 +/–
	Сообщение от Andrey Mitrofanov on 03-Мрт-17, 17:10
	>если скрипты на баше Нет, разве это не тебя там выше "петушения" и пр.камингауты беспокоили, не стесняйся? > - это харрасмент
	Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

	197. "Релиз systemd 233"	–1 +/–
	Сообщение от anomymous on 04-Мрт-17, 15:04
	> Я стесняюсь спросить, если скрипты на баше - это харрасмент, то что > же тогда конфиги sendmail? Садомазо. Не удивительно, что ditched.
	Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

	212. "Релиз systemd 233"	+1 +/–
	Сообщение от . on 04-Мрт-17, 21:03
	>Я стесняюсь спросить, если скрипты на баше - это харрасмент, то что же тогда конфиги sendmail? Скрижали дьявола! Истинно вам говорю! :-)
	Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

	161. "Релиз systemd 233"	+1 +/–
	Сообщение от freehck (ok) on 03-Мрт-17, 13:51
	> Логи все на месте (не надо верещать, что в бинарном формате, всё > равно даже текстовые смотрите с помощью отдельной утилиты). Проблема бинарного лога не в том, что с ним работать сложнее, а в том, что если он побьётся, то его невозможно восстановить.
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	228. "Релиз systemd 233"	–1 +/–
	Сообщение от Аноним (??) on 06-Мрт-17, 21:54
	Не сложнее чем побившийся /var/log/daemon.1.gz.
	Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

	229. "Релиз systemd 233"	+/–
	Сообщение от freehck (ok) on 06-Мрт-17, 23:48
	> Не сложнее чем побившийся /var/log/daemon.1.gz. Хех. Хорошая попытка, но у того же logroate компрессия по умолчанию выключена. Если демон хочет её включить - это делается явно. Чтобы выключить - надо просто закомментировать строку в /etc/logrotate.d/
	Ответить | Правка | ^ к родителю #228 | Наверх | Cообщить модератору

134. "Релиз systemd 233"	+/–
Сообщение от Аноним (??) on 03-Мрт-17, 07:52
Существенные изменения в 233 есть. Пожалуй системд стоило другую нумерацию ставить, где видно "мажорная.минорная.баг фиксы", и эта была бы можорная. > В таймерах (.timer unit) добавлена возможность указания времени относительно конца месяца через использование разделителя "~" вместо "-" между днём и месяцем. Например, "*-02~03" приведёт к срабатыванию таймера за три дня до конца февраля. Бред какой-то, зачем ставить опцию, которая заведомо делает что-то на 3 дня раньше. Запихнули бы рандом чтоли =)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	139. "Релиз systemd 233"	+1 +/–
	Сообщение от Andrey Mitrofanov on 03-Мрт-17, 09:04
	>Запихнули бы рандом чтоли =) Остановитесь!  Ведь так и до скриптов не далеко??  Нужно деражаться11111
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	227. "Релиз systemd 233"	+/–
	Сообщение от Аноним (??) on 06-Мрт-17, 21:43
	Вот так админы локалхоста и палятся.
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

135. "Релиз systemd 233"	+4 +/–
Сообщение от iCat (ok) on 03-Мрт-17, 08:26
# eselect profile set hardened # USE="-systemd" emerge --newuse system Привет сторонникам systemd
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	221. "Релиз systemd 233"	+1 +/–
	Сообщение от freehck (ok) on 05-Мрт-17, 16:24
	> # eselect profile set hardened > # USE="-systemd" emerge --newuse system > Привет сторонникам systemd Праильно! Так их! :) Package: *systemd* Pin: release * Pin-Priority: -1
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

223. "Релиз systemd 233"	+/–
Сообщение от Аноним (??) on 05-Мрт-17, 18:46
233 версия, а restart (ExecRestart) сервисов до сих пор нет умеет :-)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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