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

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

"Второй отчет о развитии системного менеджера systemd"	+/–
Сообщение от opennews (ok) on 20-Ноя-10, 14:08
Леннарт Поттеринг, возглавляющий разработку перспективной системы инициализации systemd (http://www.opennet.dev/opennews/art.shtml?num=26447), представил (http://0pointer.de/blog/projects/systemd-update-2.html) очередной отчет о развитии проекта, приуроченный к его 13-му релизу (http://lists.freedesktop.org/archives/systemd-devel/2010-Nov...). Ключевые моменты: -  Уже сейчас, в составе Fedora 15/Rawhide, systemd 13 способен обеспечить полноценную загрузку системы <i>без использования shell-скриптов</i>. Однако, все еще существуют отдельные ситуации, когда без скриптов обойтись невозможно, в частности: -  Включен autoswapping (Леннарт отмечает, что это в любом случае не лучшая идея); -  Требуется полная переустановка меток SELinux; -  Выполняется первая загрузка после установки системы; -  Производится загрузка модулей ядра, сконфигурированная без использования соответствующего штатного механизма systemd; -  Производится загрузка с доступной только на чтение... URL: http://0pointer.de/blog/projects/systemd-update-2.html Новость: http://www.opennet.dev/opennews/art.shtml?num=28713
Ответить | Правка | Cообщить модератору

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

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

1. "Второй отчет о развитии системного менеджера systemd"	+18 +/–
Сообщение от dimqua (ok) on 20-Ноя-10, 14:08
Одно слово. Впечетляет.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	30. "Второй отчет о развитии системного менеджера systemd"	–2 +/–
	Сообщение от User294 (ok) on 20-Ноя-10, 17:47
	Действительно, список фич внушительный. И в эмбеддовке такой подход подойдет - там выполнение скриптов зачастую сильно сажает скорость загрузки.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Второй отчет о развитии системного менеджера systemd"	+7 +/–
Сообщение от mrd_kaluga on 20-Ноя-10, 14:21
А я почему-то всегда думал что скрипты - это преимущество. Всегда можно посмотреть как что сделано или поменять. А с systemd в купе с обычной бедностью man-ов в Линуксе вообще теперь сложно будет сказать где что и как работает. И без компилятора (который не ставится обычно на production машинах) ничего не поменяешь, я так понимаю. Хотя посмотрим, может действительно окажется удобнее..
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Второй отчет о развитии системного менеджера systemd"	+5 +/–
	Сообщение от zerot (ok) on 20-Ноя-10, 14:26
	скрипты это большой плюс, если вы хотите иметь контроль над системой и вам некритично время загрузки - пять или сто секунд. На серверах и десктопах обычно так и есть - просто разводят очередную истерию. Берегите свою психику ...
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	5. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от mrd_kaluga on 20-Ноя-10, 14:29
	Кстати, не знаю как в федоре, но в CentOS уже сеть запихали в NetworkManager (по-моему так называется), черную коробку. Наверное для desktop-ов хорошо, а на сервере уже страшновато становится немного: зачем статику через демона назначать?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	6. "Второй отчет о развитии системного менеджера systemd"	+6 +/–
	Сообщение от dalco (ok) on 20-Ноя-10, 14:35
	Так вроде никто не мешает этот NetworkManager отключить и работать по старинке? В моих серваках (правда, там Fedora) он отключен, но жизнь продолжается :)
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	8. "Второй отчет о развитии системного менеджера systemd"	–6 +/–
	Сообщение от анон on 20-Ноя-10, 14:53
	>Кстати, не знаю как в федоре, но в CentOS уже сеть запихали в NetworkManager (по-моему так называется), черную коробку. Дайте угадаю. Вы - пользователь Ubuntu, редхатов никогда до этого не видели, поставили "крутой серверный дистрибутив" CentOS в виртуалку "на посмотреть". В инсталляторе, естественно, отметили установку "Графическое окружение GNOME" (включая NetworkManager). После установки полезли в /etc/network/interfaces... А его нет! Ужас-ужас-ужас! Предатели! Изменники! Весь сервер теперь только через NM настраивать!!!1 Открою вам страшную тайну: в редхатовских дистрах сеть настраивается через /etc/sysconfig/network-scripts/ifcfg-*. И, разумеется, никакой NM этого не отменяет. Читайте документацию - классная штука! ;-)
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	12. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от Egres (ok) on 20-Ноя-10, 15:04
	В CentOS 5.xx всё хорошо, а вот в 9-й (что ли) Федоре ставится этот самый network manager безо всяких иксов и именно он стартует по-умолчанию (сервис network отключён)
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	43. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от Gular (ok) on 21-Ноя-10, 08:46
	Да Fedora вообще плохой вариант для сервера. В пробовали устанавливать ее не в графике, а в текстовом режиме (установщик ncurses)? В RHEL/CentOS он работает адекватно, а у нее при тако варианте: а) не предлагается размечать диски _вообще_ (сетапится по дефолту, с LVM и ext4); б) не предлагается выбрать, что ставить, в результате потом тянется куча GUI. Это только в случае текстового режима; в графике все хорошо. Но сами понимаете, сетапить ОС, скажем, через IP-KVM в графике - неуважение самому к себе. Единственное, в чем лучше Fedora на сервере, это более новый софт. Правда не редко, когда в продакшн софт собирается в локальных репах, и все что надо, и как надо, есть и так. В этом случае Fedora нахрен не нужна.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	45. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от dalco (ok) on 21-Ноя-10, 09:52
	>Да Fedora вообще плохой вариант для сервера. Выбор того или иного дистрибутива для сервера - личное дело конкретного админа в конкретном софтовом/железячном окружении. Скажем, у меня нет проблем с Fedora - переставляю что-либо крайне редко (просто виртуальные машины переползают с хоста на хост или создаются новые из шаблона), имею физический доступ к серверам, да и каналы связи до фермы достаточно мощные. Мой друг знать ничего не хочет кроме оффтопика, но зато он этот самый оффтопик подымет влет из любого положения. И любой школьник-эникейщик сможет потом все это поддерживать/заломать снова :) Еще кто-то любит сервера на debian, кто-то порвет глотку за gentoo... В общем, не надо громких заявлений, что "дистрибутив XXX для сервера - suxxx, а дистрибутив YYY - единственно верное решение", ибо от ситуации зависит... ;)
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	27. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от jbo (??) on 20-Ноя-10, 17:23
	> Открою вам страшную тайну: в редхатовских дистрах сеть настраивается через /etc/sysconfig/network-scripts/ifcfg-*. И, разумеется, никакой NM этого не отменяет. в убунте тоже есть 1 файлик /etc/network/interfaces человек говорил про CentOS а вы начали грязью поливать Ubuntu
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	68. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от анон on 21-Ноя-10, 23:42
	> человек говорил про CentOS а вы начали грязью поливать Ubuntu Интересные у вас какие-то представления о жизни: "посоветовать читать документацию" по-вашему "полить грязью". Воистину, странные вы люди.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	84. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от Petja_s_upravdoma (ok) on 22-Ноя-10, 08:26
	>> человек говорил про CentOS а вы начали грязью поливать Ubuntu > Интересные у вас какие-то представления о жизни: "посоветовать читать документацию" по-вашему "полить грязью". > Воистину, странные вы люди. Ну да, ну да ... не страннее некоторых ... угу ...
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	34. "Второй отчет о развитии системного менеджера systemd"	–1 +/–
	Сообщение от stranger (??) on 20-Ноя-10, 18:01
	Я Вам сейчас открою страшную тайну - в RHEL 6 сеть иначе чем через NM не настраивается. system-config-network есть, но не работает.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	35. "Второй отчет о развитии системного менеджера systemd"	+1 +/–
	Сообщение от Stax (ok) on 20-Ноя-10, 19:40
	Выключить сервис NetworkManager, включить network - и вуаля - пробовали ? :) Между прочим, вполне реальный совет из редхатовской багзиллы по поводу проблем с сетью (правда, как в итоге выяснилось, NM был не при чем и заработало и с ним) Кстати можно первый не выключать, если зачем-то требуется. Достаточно включить network и разрулить в файликах /etc/sysconfig/network-scripts: чему разрешено управляться через NM, чему нет. Сервис network "автомагически" будет рулить только теми интерфейсами, которые запрещено трогать NM'у.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	36. "Второй отчет о развитии системного менеджера systemd"	–3 +/–
	Сообщение от zerot (ok) on 20-Ноя-10, 20:39
	а не проще добавить в начало скрипта /etc/init.d/network_manager (или как он там называется) строчку exit 0 ; и настраивать всё без NetworkManager проверенными способами (через типовые конфиги) ? при этом не болит голова с выкидыванием пакетов, которые могут оказаться в зависимостях у других пакетов, но вредный функционал не отрабатывает ...
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	38. "Второй отчет о развитии системного менеджера systemd"	+1 +/–
	Сообщение от Stax (ok) on 20-Ноя-10, 23:28
	Нет, зачем хакать пакет (к тому же при апдейте затрется), можно просто отключить выполнение этого сервиса через chkconfig/ntsysv/system-config-services etc :p Но network тоже надо не забыть включить - по дефолту выключен
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	39. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от zerot (ok) on 21-Ноя-10, 00:12
	> Нет, зачем хакать пакет (к тому же при апдейте затрется), можно просто > отключить выполнение этого сервиса через chkconfig/ntsysv/system-config-services etc таким образом вы только запретите старт/стоп при запуске соответствующего кольца исполнения (например в RH = 5 или 3, в Debian = 2, посмотреть можно в /etc/inittab). Но есть ещё всякие новомодные механизмы, которые учитывают зависимости и при старте/стопе такого дочернего сервиса заодно стартуют и сервисы, от которых он зависит то есть ваш скрипт /etc/init.d/XXX может запускаться из разных мест. Так что добавление exit 0 ; в начале такого скрипта (после #!/bin/bash) позволит стартовать скрипт откуда угодно, но отрабатывать он будет только команду выхода. И пусть всякие "хитропопые" надстройки стартуют его на здоровье - делаться при этом ничего не будет, только будет возвращаться 0 - признак того, что всё отработало на ура. Результат вы получаете самой малой кровью а чтобы не затиралось при апдэёте, можно выставить имунный бит chattr +i имя_файла и это верно - у вас есть файлы, которые не должны меняться, это ваше частное решение. Для этого есть штатные механизмы
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	44. "Второй отчет о развитии системного менеджера systemd"	+1 +/–
	Сообщение от Gular (ok) on 21-Ноя-10, 09:03
	И все же. Собственно, это не единственный такой способ. Но делать такое - это неправильное решение проблемы. Т.е. это будет работать, но не кошерно. Почему - выше написали. После обновления будет Вам /etc/init.d/networkmanager.rpmsave. Лучше удалить NM совсем. Особенно если сетапы идут через PXE. В таких случаях всё заливается при сетапе, и NM не нужен.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	56. "Второй отчет о развитии системного менеджера systemd"	–3 +/–
	Сообщение от zerot (ok) on 21-Ноя-10, 13:34
	опять же неверно. при попытке удалить NM пакетный менеджер предложит удалить и все зависимые от него пакеты, среди которых может оказаться, например KDE или Гном. вариантов решения здесь масса, например фиктивные пакеты в Дебиане, или сделать пустой пакет NM - заглушку. Но самый простой путь из добавления одной строки описан мной выше - дальше просто - мне удобно так. и кошерно и православно и т.д., кому не нравится - пусть делает по своему
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	94. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от Gular (ok) on 22-Ноя-10, 13:23
	Да, выше имел ввиду сервер. :) Для десктопа конечно, да и лучше наверно будет настраивать подключение через NM. Хотя стандартные методы никто не отменял, NM справляется вполне.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	113. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от Зилибоба (ok) on 22-Ноя-10, 17:49
	Обожаю никсы именно за это. 1000+1 способ некоршерного решения проблемы =). К слову, если настроить в убунте, сеть через конфигфайл, то настроенный там интерфейс NM будет игнорировать.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	62. "Второй отчет о развитии системного менеджера systemd"	+1 +/–
	Сообщение от reminux (ok) on 21-Ноя-10, 16:31
	> а чтобы не затиралось при апдэёте, можно выставить имунный бит > chattr +i имя_файла > и это верно - у вас есть файлы, которые не должны меняться, > это ваше частное решение. Для этого есть штатные механизмы То есть месье таким образом гарантированно "защитит" этот скрипт от любых багфиксов/улучшений/дополнений, которые в него позднее могут быть внесены его авторами или мантейнерами.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	64. "Второй отчет о развитии системного менеджера systemd"	–1 +/–
	Сообщение от zerot (ok) on 21-Ноя-10, 22:39
	> То есть месье таким образом гарантированно "защитит" этот скрипт от любых багфиксов/улучшений/дополнений, > которые в него позднее могут быть внесены его авторами или мантейнерами. именно - задача "малой кровью" избавиться от запуска и от функциональности этого пакета, и в т.ч. скрипта запуска, не парясь зависимостями и т.п. издеся месье знает что делает и для чего - не сомневайтесь :) а в других случаях делает иначе ...
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	67. "Второй отчет о развитии системного менеджера systemd"	+2 +/–
	Сообщение от анон on 21-Ноя-10, 23:40
	>именно - задача "малой кровью" избавиться от запуска и от функциональности этого пакета, и в т.ч. скрипта запуска, не парясь зависимостями и т.п. Эта задача решается двумя командами chkconfig NetworkManager off chkconfig network on А месье занимается клоунадой.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	86. "Второй отчет о развитии системного менеджера systemd"	–2 +/–
	Сообщение от zerot (ok) on 22-Ноя-10, 10:11
	это проговаривалось выше, вы невнимательны
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	88. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от анон on 22-Ноя-10, 11:44
	>это проговаривалось выше, вы невнимательны Я внимателен, и поэтому заметил, что вы не привели никаких возражений, почему данный метод хуже вашего. Технически грамотных возражений, я имею в виду. А вот недостатки вашего метода (в частности, сложность, регулярный гемор при обновлении) вполне очевидны.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	99. "Второй отчет о развитии системного менеджера systemd"	+2 +/–
	Сообщение от non anon on 22-Ноя-10, 14:36
	>таким образом вы только запретите старт/стоп при запуске соответствующего кольца исполнения (например в RH = 5 или 3, в Debian = 2, посмотреть можно в /etc/inittab) Может быть, вы таки почитаете man chkconfig? Команда "chkconfig NetworkManager off" выключит nm на всех ранлевелах, к вашему сведению. >Но есть ещё всякие новомодные механизмы, которые учитывают зависимости и при старте/стопе такого дочернего сервиса заодно стартуют и сервисы, от которых он зависит Ну-ка, ну-ка, приведите примеры таких механизмов? Естественно, со ссылками на маны, где сказано, что они именно "самовольно запускают отключенные сервисы для удовлетворения зависимостей". И особенно приветствуются доказательства наличия этих механизмов в дефолтной установке CentOS (мы же о нем говорим?).
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	104. "Второй отчет о развитии системного менеджера systemd"	–1 +/–
	Сообщение от zerot (ok) on 22-Ноя-10, 14:54
	мистер анон, гадить в разговоре, а дальше делать вид что не гадили и ждать продолжения диалога не проканает (см. прежние посты). сказать что мне в принципе есть, но вас уже нет
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	106. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от non anon on 22-Ноя-10, 15:06
	Т.е. вам нечего возразить по сути?
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	116. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от Michael Shigorin (ok) on 23-Ноя-10, 09:42
	> chattr +i имя_файла Об это потом споткнётся обновление -- станет болтаться минимум один пакет, который каждый раз будет пытаться обновиться и неудачно. Если что-либо настолько мешает жить, обычно лучше его снести. > Для этого есть штатные механизмы Это если он %config(noreplace), в чём я лично не уверен (проверить сейчас неудобно, gprs). PS: а вообще Леннарт будто оправился от пульса и опять в конструктивное русло :)
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	120. "Второй отчет о развитии системного менеджера systemd"	–1 +/–
	Сообщение от zerot (ok) on 24-Ноя-10, 06:27
	ну, chattr приведён больше для примера . кстати метод "exit 0;" впервые пришлось применять именно на Дебиане, ибо там NM в зависимостях у кучи пакетов. На rhel/centos этого делать до сих пор не приходилось
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	121. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от aborland on 24-Ноя-10, 12:42
	Да вы бредите^w не пробовали его удалять, а я пробовал :-) NM отлично сносится и система без него отлично работает aptitude purge network-manager Следующие пакеты будут УДАЛЕНЫ:   dnsmasq-base{u} iputils-arping{u} network-manager{p} network-manager-gnome{a} из которых dnsmasq-base и iputils-arping используются самим NM и при его удалении больше не нужны
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	122. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от zerot (ok) on 24-Ноя-10, 13:24
	> Да вы бредите^w не пробовали его удалять, а я пробовал :-) > NM отлично сносится и система без него отлично работает не брежу, но возможно путаю с убунтой. Помню, что это было что то Debian based. Времени воскресить этот момент примерно двухгодичной давности нет, но на отдельных инсталляциях этот метод у меня работает, и раз он работает, то достоин упомянания в этом обсуждении ИМХО
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	61. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от анон on 21-Ноя-10, 16:18
	>а не проще добавить в начало скрипта >/etc/init.d/network_manager (или как он там называется) >строчку >exit 0 ; ... и при следующем апдейте все это будет перекрыто дефолтным скриптом, и при следующей загрузке NM запустится и устроит драку с классическими ifup/ifdown. Браво! Можно, конечно, развить эту идею дальше, и заблокировать скрипт от изменений (например, через атрибуты фс). Тогда на середние апдейта ВНЕЗАПНО упадёт пакетный менеджер, и при следующей перезагрузке система может вообще не загрузиться. Классно! Дорогой zerot, апологет ректальной тонзиллэктомии! You made my day, thank you very much!
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	65. "Второй отчет о развитии системного менеджера systemd"	–3 +/–
	Сообщение от zerot (ok) on 21-Ноя-10, 22:48
	> Можно, конечно, развить эту идею дальше, и заблокировать скрипт от изменений (например, > через атрибуты фс). Тогда на середние апдейта ВНЕЗАПНО упадёт пакетный менеджер, > и при следующей перезагрузке система может вообще не загрузиться. Классно! эта адская картина не обязательно соответствует действительности, даже если говорить про апдейт, а не загрузку системы. Даже зачастую не соответствует. И потом, вы же на продакшене (хоть сервера хоть workstation) не обновляетесь, не пройдя обновление на тестовой среде ? Домашняя машина у вас наверняка рядом с болванкой LiveCD, чтобы при отказе загрузки восстановиться руками. Да и смотрите наверняка, какие пакеты будут обновляться.  Батюшка поп, зачем прихожан пугаете ? > Дорогой zerot, апологет ректальной тонзиллэктомии! You made my day, thank you very > much! да, как мало вам нужно для активации проявления следов высшей нервной деятельности, сдобренной знаниями этикета, околомедицинской терминологии и какого то :) нерусского языка
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	41. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от fa (??) on 21-Ноя-10, 06:07
	Можно вопрос. Зачем NetworkManager так активно впихивают во все дистрибутивы?
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	60. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от Аноним (??) on 21-Ноя-10, 15:18
	Ничего лучше нет для хомячков и не только для них. Удобная штука!
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	123. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от Michael Shigorin (ok) on 25-Ноя-10, 16:44
	Отучаемся говорить за всех, пушистый Вы наш.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	58. "Второй отчет о развитии системного менеджера systemd"	+1 +/–
	Сообщение от prapor (??) on 21-Ноя-10, 14:46
	В /etc/sysconfig/network-scripts/ifcfg-eth0 (для примера) пишем NM_CONTROLLED="no" и получаем всё по-старинке.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	119. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от mrd_kaluga on 24-Ноя-10, 02:12
	Ой как много уже определений для меня. Не знаю что такое Gnome, графикой в Линуксе не знаю как пользоваться. Нашел это в CentOS, другого вроде нет. Всего 100 серверов с "крутой серверной ОС". Извините если не слишком круто. И да, мы вообще ламеры по сравнению с Вами :)
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	126. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от zerot (ok) on 26-Ноя-10, 08:01
	не удержался знакомый таширский говорок :) а, кстати 100 серверов не всегда в плюс. На меньшем количестве почему не смогли сделать ? :)
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	55. "Второй отчет о развитии системного менеджера systemd"	+1 +/–
	Сообщение от mirr0r (ok) on 21-Ноя-10, 11:47
	> Кстати, не знаю как в федоре, но в CentOS уже сеть запихали > в NetworkManager (по-моему так называется), черную коробку. Наверное для desktop-ов хорошо, > а на сервере уже страшновато становится немного: зачем статику через демона > назначать? Отключите и не парьтесь )
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	90. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от TeXHaPb (ok) on 22-Ноя-10, 11:55
	В Debian Squeeze почему-то NM работает только с теми интерфейсами, что не перечислены в /etc/network/interfaces. ЧЯДНТ?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	7. "Второй отчет о развитии системного менеджера systemd"	+1 +/–
	Сообщение от Морозов Алексей on 20-Ноя-10, 14:49
	Есть одно место, где высокая скорость загрузки роляет - мобильные устройства. К сожалению, время работы от батарейки не так велико, как хотелось бы. Если загрузка быстрая, то можно не пользоваться хибернейтом (который всё равно выжирает батарейку), а делать честный шатдаун...
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	14. "Второй отчет о развитии системного менеджера systemd"	+1 +/–
	Сообщение от zerot (ok) on 20-Ноя-10, 15:30
	согласен, поэтому и написал про сервера и десктопы у мобильных устройств своя специфика. там, например, предпочтительнее использовать скандально :) известный BusyBox. Но это специфика мобильных истройств, и тянуть её неудобные идеи на десктопы и сервера неверно ИМХО
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	32. "Второй отчет о развитии системного менеджера systemd"	–2 +/–
	Сообщение от User294 (ok) on 20-Ноя-10, 17:57
	> Если загрузка быстрая, то можно не пользоваться хибернейтом (который всё равно > выжирает батарейку), а делать честный шатдаун... Не оправдано, как минимум для устройств типа мобилок: сам процесс загрузки очень энергоемок. В режиме сна современная цифра почти ничего не потребляет. А вот при загрузке проц и память лупят на полную, экран светит, периферия инициализируется вместо того чтобы спать и прочая. Это легко сожрет энергию которой бы на много часов сна хватило. Исключение разве что ноуты на интеле, однако даже там у хибернейта есть крупный плюс: вы немедленно попадаете в ваше прошлое рабочее окружение а не нулевую систему после загрузки. Что как-то сильно удобнее - если пришлось прервать работу, можно продолжить ее точно с того же места, без каких-либо телодвижений и очень быстро. Но это не значит что перезагрузка должна тормозить и в этом плане systemd выглядит интересно.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	46. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от XoRe (ok) on 21-Ноя-10, 10:39
	Думаю, человек имел в виду нетбуки и прочие айпады. Мобильные телефоны вообще не выключаются )
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	112. "Второй отчет о развитии системного менеджера systemd"	–1 +/–
	Сообщение от User294 (ok) on 22-Ноя-10, 17:19
	> Думаю, человек имел в виду нетбуки и прочие айпады. Даже на нетбуках и ипадах режим сна довольно экономный (на лично моем девайсе - девайс в нем может валяться эдак ~неделю). А почти моментальное восстановление в предыдущее рабочее окружение - рулит и педалит. Однако ж быстрая загрузка все-равно никому еще не вредила. > Мобильные телефоны вообще не выключаются ) Это вы так думаете. А оказывается - бывают извращенцы, которые пытаются "экономить" батарейку путем именно выключения телефона на ночь и прочая. На практике результат такой "экономии" запросто получается со знаком минус. Прито те крохи которы за ночь скушает проц не идут ни в какое сравнение с тем что он+лцдха+рег в сети+прочая сожрут при ребуте :). И тем не менее, а согласитесь что загружающийся 2 минуты телефон - тоже не прикольно? :)
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	128. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от XoRe (ok) on 27-Ноя-10, 02:50
	>И тем не менее, а согласитесь что загружающийся 2 минуты телефон - > тоже не прикольно? :) Учитывая аппаратные характеристики телефонов и кучу явы в ПО, 2 минуты - это чудо =)
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	9. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от анон on 20-Ноя-10, 14:57
	> скрипты это большой плюс, если вы хотите иметь контроль над системой Вы - пользователь LFS? Никто, кроме LFS'ников, не имеет морального права так говорить. Если у вас нормальный дистрибутив, то, как бы вы ни правили ваши скрипты, при следующем обновлении они всё равно заменятся на дефолтные, и ваша система начнёт вести себя совсем по-другому. Поттеринг предлагает совершенно другой путь - вместо ковыряния в потрохах скриптов, использовать продуманные программы с гибкими настройками на все случаи жизни. Путание исполняемого кода и конфигурационного файла - старая болезнь разработчиков Unix, хотя этот принцип прямо противоречит модульной концепции разработки, исповедуемой в этом семействе ОС.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	10. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от анон on 20-Ноя-10, 15:00
	> Путание исполняемого кода и конфигурационного файла - старая болезнь разработчиков Unix, > хотя этот принцип прямо противоречит модульной концепции разработки, исповедуемой в этом > семействе ОС. В результате и получаем справедливые насмешки: "Unix - это не куча костылей и подпорок, Unix - это тщательно продуманная система костылей и подпорок!"
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	63. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от анонимус с опеннета on 21-Ноя-10, 22:05
	>> Путание исполняемого кода и конфигурационного файла - старая болезнь разработчиков Unix, >> хотя этот принцип прямо противоречит модульной концепции разработки, исповедуемой в этом >> семействе ОС. > В результате и получаем справедливые насмешки: "Unix - это не куча костылей > и подпорок, Unix - это тщательно продуманная система костылей и подпорок!" 1. Скрипты и конфигурационные файлы не "путаются", а каждый выполняет свою задачу. 2. Параллельное наличие и скриптов, и конфигов в полной мере соответствует модульной концепции. Есть кошерное дистрибутивное решение - правим конфиги. Нет (случается и такое) - приходится править скрипты. При отсутствии скриптов в данном случае пришлось бы править исходники и компилить. Сам я приверженец кошерных методов и при необходимости отключить сервис exit 0 в загрузочный скрипт не дописываю, но на практике все же приходилось править как скрипты, так и исходники. Ктоме того скрипты способствуют прозрачности загрузки.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	69. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от анон on 21-Ноя-10, 23:48
	> 2. Параллельное наличие и скриптов, и конфигов в полной мере соответствует модульной > концепции. Есть кошерное дистрибутивное решение - правим конфиги. Нет (случается и > такое) - приходится править скрипты. Почему же ещё никто не переписал на скриптах тот же apache? Когда люди находят ошибку или отсутствие архиважной функции в бинарной программе, они, как правило, пишут патч и отсылают на багтрекер. Когда людям нужно расширение функциональности бинарной программы, они пользуются механизмом плагинов. Причем, в целях упрощения плагиностроения, плагины могут быть и скриптами. Именно по таким принципам строится systemd. А скриптовая природа существующих систем загрузки - это лишь отголосок первоначального хаоса ранней эпохи Unix, но никак не эталон.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	70. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от анон on 21-Ноя-10, 23:51
	> Когда людям нужно расширение функциональности бинарной программы, они пользуются механизмом плагинов. Уточняю: здесь речь идёт о добавлении достаточно специализированных функций, которые не нужны большинству пользователей программы, но нужны меньшинству. Например, исполнение некой команды в /etc/rc.local. У юзера Васи там прописан запуск сервера counter-strike, а у юзера Пети, например, смена мак-адреса (ну не осилил он штатные средства дистрибутива).
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	81. "Второй отчет о развитии системного менеджера systemd"	–5 +/–
	Сообщение от kshetragia (ok) on 22-Ноя-10, 06:52
	Это проблемы Васи. Почему я как разработчик должен учитывать таких дол..ов? Гораздо лучше будет если объяснить ему насколько он не прав. Подобными вывертами Линукс роет себе яму.    По теме этой поделки... Upstart + легковесный шелл - и ваши волосы будут мягкими и шелковистыми. Только не нужно пытаться объяснять насколько крут systemd. Никогда не поверю, что сервера вы выключаете на ночь и каждое утро бутите заново. Или может быть дома у вас нет пары минут, чтобы дождаться загрузки? Для различного рода потаскунов есть спящий режим. Вобщем это один из тех проектов, который нужно душить в зародыше.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	85. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от Petja_s_upravdoma (ok) on 22-Ноя-10, 08:31
	>    Это проблемы Васи. Почему я как разработчик должен учитывать > таких дол..ов? Праильна, лучше ходить под себя ... чем в отхожее место.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	92. "Второй отчет о развитии системного менеджера systemd"	–1 +/–
	Сообщение от kshetragia (ok) on 22-Ноя-10, 12:40
	>>    Это проблемы Васи. Почему я как разработчик должен учитывать >> таких дол..ов? > Праильна, лучше ходить под себя ... чем в отхожее место. Скажите, а по улице вы тоже с горшком ходите для страждущих? Или все-таки указываете им где можно справить нужду? Из-за такого вот не в меру активного лизания всем желающим система медленно, но верно превращается в помойку.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	115. "Второй отчет о развитии системного менеджера systemd"	–2 +/–
	Сообщение от mr_gfd on 23-Ноя-10, 01:18
	>>>    Это проблемы Васи. Почему я как разработчик должен учитывать >>> таких дол..ов? >> Праильна, лучше ходить под себя ... чем в отхожее место. > Скажите, а по улице вы тоже с горшком ходите для страждущих? Или > все-таки указываете им где можно справить нужду? Из-за такого вот не > в меру активного лизания всем желающим система медленно, но верно превращается > в помойку. Видел я конторы таких разработчиков. На 4 этажа - 1 отхожее место, 2 писсуара и 3 кабинки. зассано и засрано, а потом еще и растоптано. Вот путь джедаев, да. Это я все к тому, что разработчик думает, что знает как должно быть, хоть это задача архитектора.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	117. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от kshetragia (ok) on 23-Ноя-10, 10:35
	Хм.. в Линуксе уже появились архитекторы?
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	89. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от анон on 22-Ноя-10, 11:48
	> По теме этой поделки... Upstart + легковесный шелл - и ваши волосы будут мягкими и шелковистыми. От созерцания долго и неторопливо грузящейся системы мои волосы становятся жесткими, как щетина. Я хочу почитать свежие темы на форуме, пока мой утренний кофе не остыл. Так что не катит. > Вобщем Linux это один из тех проектов, который нужно душить в зародыше. В принципе, вы могли бы ограничиться этим утверждением, которое полностью раскрывает ваше мировоззрение.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	91. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от kshetragia (ok) on 22-Ноя-10, 12:36
	>> Вобщем Linux это один из тех проектов, который нужно душить в зародыше. > В принципе, вы могли бы ограничиться этим утверждением, которое полностью раскрывает ваше > мировоззрение. Ох..тельно. Зачем приписывать мне то, чего я не говорил?
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	96. "Второй отчет о развитии системного менеджера systemd"	–2 +/–
	Сообщение от non anon on 22-Ноя-10, 14:20
	> Ох..тельно. Зачем приписывать мне то, чего я не говорил? Какая разница, что кричит неадекват... )
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	93. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от kshetragia (ok) on 22-Ноя-10, 12:43
	>> По теме этой поделки... Upstart + легковесный шелл - и ваши волосы будут мягкими и шелковистыми. > От созерцания долго и неторопливо грузящейся системы мои волосы становятся жесткими, как > щетина. Я хочу почитать свежие темы на форуме, пока мой утренний > кофе не остыл. Так что не катит. Уже обсасывали эту тему(как ни странно на лоре иногда бывают адекватные люди). Основная проблема - bash слишком тяжел для скриптов инициализации. На Фрюше такой проблемы не существует.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	95. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от non anon on 22-Ноя-10, 14:19
	>Основная проблема - bash слишком тяжел для скриптов инициализации. Убунта с апстартом и дашем грузится так мучительно медленно, что любой кофе пять раз остынет. Проблема здесь в архитектуре, а не в конкретных средствах.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	18. "Второй отчет о развитии системного менеджера systemd"	–3 +/–
	Сообщение от zerot (ok) on 20-Ноя-10, 15:39
	> Вы - пользователь LFS? Никто, кроме LFS'ников, не имеет морального права так говорить очередной иудо - христианин с можно и нельзя ? Захочется - будем использовать микроскоп для забивания гвоздей, если это даст искомый результат искомым путём. Правда здесь как раз наоборот - скрипты это адекватно > Если у вас нормальный дистрибутив, то, как бы вы ни правили ваши > скрипты, при следующем обновлении они всё равно заменятся на дефолтные, и > ваша система начнёт вести себя совсем по-другому. неверно. всегда есть какой нибудь rc.local, который оставляют для того, чтобы вы написали свой алгоритм > Поттеринг предлагает совершенно другой путь - вместо ковыряния в потрохах скриптов, использовать > продуманные программы с гибкими настройками на все случаи жизни. на мой взгляд раздувается истерия там, где нужно просто научиться пользоваться типовыми механизмами. Не умеете пользоваться профессиональным инструментом - скриптами - не администратор UNIX, а желающий присоседиться чайник > Путание исполняемого кода и конфигурационного файла - старая болезнь разработчиков Unix, > хотя этот принцип прямо противоречит модульной концепции разработки, исповедуемой в этом > семействе ОС. Это не болезнь, а принцип организации работ, позволяющий качественно и наглядно получать результат. Не надо за меня продумывать, я не персонаж из стада христова, предоставьте функциональные кубики, и я свяжу их нужными скриптами. Правда желающим влезть прослойкой со своими идеями и толкованиями места не останется - так туда им и дорога
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	22. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от анон on 20-Ноя-10, 15:49
	> Захочется - будем использовать микроскоп для забивания гвоздей, если это даст искомый результат искомым путём. Идейный противник молотков? > Правда здесь как раз наоборот - скрипты это адекватно И правда, сибирский админ, отвергающий конфиги и настраивающий программу правкой кода. Смеялся :-D > неверно. всегда есть какой нибудь rc.local, который оставляют для того, чтобы вы > написали свой алгоритм Вы не поверите... в systemd всегда можно вызвать произвольный скрипт или команду. Но в стандартном процессе загрузки, который устраивает 99.9% пользователей, без этого можно обойтись. > на мой взгляд раздувается истерия там, где нужно просто научиться пользоваться типовыми механизмами. Не умеете пользоваться профессиональным инструментом - скриптами - не администратор  UNIX, а желающий присоседиться чайник По-вашему, "типовой механизм" - это настройка программы через редактирование её кода? Да вы смешной человек ;-) > Это не болезнь, а принцип организации работ, позволяющий качественно и наглядно получать результат. (C) Bill Gates. Amen.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	24. "Второй отчет о развитии системного менеджера systemd"	–1 +/–
	Сообщение от zerot (ok) on 20-Ноя-10, 16:19
	> Идейный противник молотков? сторонник принятия адекватных решений > И правда, сибирский админ, отвергающий конфиги и настраивающий программу правкой кода. попутали, про компилятор писал не я. Впрочем поддерживаю оратора > Смеялся :-D к чему вы это написали ? > Вы не поверите... в systemd всегда можно вызвать произвольный скрипт или команду. > Но в стандартном процессе загрузки, который устраивает 99.9% пользователей, без этого можно обойтись Пусть пробуют, если будет удобнее для администратора - администратор перейдёт через несколько лет. А так жалко времени и внимания, их есть куда тратить и они не безграничны > По-вашему, "типовой механизм" - это настройка программы через редактирование её кода? для скриптового метода - это конечно так. Самый что ни на есть UNIX way. Не плодите сущностей сверх меры > Да вы смешной человек ;-) в мире масса людей, не понимающих что к чему ((С) Маширо). Видите ли, когда кто то мешает мне жить, пытается там манипулировать, смехом например, я просто зачисляю его в нелюдь и быдлоиды. Прекрасный еврейский (и не только) приём, позаимствованный среди прочих для удобства жизни. Что там делает эта обезьяна - вам ведь уже не важно :) Это в 20 лет можно "вестись" на такой стиль разговора, а потом времени и желания на понимание чужих нет. Так что для конструктивного диалога учитесь строить разговор без манипулятивных методов > (C) Bill Gates. Amen. must die. Карфаген должен быть разрушен :)
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	59. "Второй отчет о развитии системного менеджера systemd"	+1 +/–
	Сообщение от reminux (ok) on 21-Ноя-10, 15:11
	Вы в курсе, что у дистрибутивов redhat-ветки в /etc/sysconfig есть конфиги для многих init-скриптов, специально для того, чтобы не надо было руками в эти init-скрипты лезть?
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	66. "Второй отчет о развитии системного менеджера systemd"	–1 +/–
	Сообщение от zerot (ok) on 21-Ноя-10, 22:50
	> Вы в курсе, что у дистрибутивов redhat-ветки в /etc/sysconfig есть конфиги для > многих init-скриптов, специально для того, чтобы не надо было руками в > эти init-скрипты лезть? не сомневайтесь. Даже знаю где лежат маны по этой надстройке, ибо регулярно забываю параметры, и держу за штатное средство :) на редхате естественно
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	72. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от анон on 21-Ноя-10, 23:53
	>> Вы в курсе, что у дистрибутивов redhat-ветки в /etc/sysconfig есть конфиги для >> многих init-скриптов, специально для того, чтобы не надо было руками в >> эти init-скрипты лезть? > не сомневайтесь. Даже знаю где лежат маны по этой надстройке, ибо регулярно > забываю параметры, и держу за штатное средство :) на редхате естественно Ага. Полный список файлов из /etc/sysconfig с припиской "Эти файлы НЕ РЕДАКТИРОВАТЬ НИ В КОЕМ СЛУЧАЕ! Править ТОЛЬКО одноимённые скрипты в /etc/init.d!" :-D
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	76. "Второй отчет о развитии системного менеджера systemd"	–1 +/–
	Сообщение от анон on 22-Ноя-10, 00:19
	> сторонник принятия адекватных решений По-моему, с ваших адекватных решений все местные читатели уже под стол сползли. Мне вот интересно: вы стебётесь или действительно так думаете? Если второе, то горячо надеюсь, что вы не админом работаете. >> По-вашему, "типовой механизм" - это настройка программы через редактирование её кода? > для скриптового метода - это конечно так. Самый что ни на есть > UNIX way. Не плодите сущностей сверх меры Т.е. вынести из скрипта блок с определением настроек, по-вашему, не-Unix way? Bad news for you, большинство init-скриптов противоречат вашему юниксвею. >> Да вы смешной человек ;-) > в мире масса людей, не понимающих что к чему ((С) Маширо). Видите > ли, когда кто то мешает мне жить, пытается там манипулировать, смехом > например, я просто зачисляю его в нелюдь и быдлоиды. Маленький злобный упёртый человечек не менее смешон, чем просто маленький упёртый человечек :-) >> (C) Bill Gates. Amen. >must die. Карфаген должен быть разрушен :) Странно. Ведь ваши взгляды на программирование практически совпадают. За что ж вы его так не любите?
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	82. "Второй отчет о развитии системного менеджера systemd"	–3 +/–
	Сообщение от zerot (ok) on 22-Ноя-10, 07:35
	отметим, что у скриптов тоже могут быть конфиги, странно, что вы до этого не додумались и с пеной у рта пытаетесь приписать другим несвойственные им взгляды. Странно, что в нитках обсуждения вы не читаете то, что писали сверху, и пытаетесь заходить на второй круг по уже проговоренному
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	101. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от non anon on 22-Ноя-10, 14:39
	> отметим, что у скриптов тоже могут быть конфиги, Судя по вашим репликам выше, вы должны рассматривать такой подход как порочный. Ведь если у скриптов есть конфиги, то в потроха исполняемого кода лезть уже не нужно. И чем тогда скрипты будут лучше бинарников?
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	40. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от Пользователь Debian on 21-Ноя-10, 03:36
	В дебиане не затрутся. Перейдите на нормальный дистрибутив и всё будет хорошо.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	73. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от анон on 21-Ноя-10, 23:55
	> В дебиане не затрутся. Перейдите на нормальный дистрибутив и всё будет хорошо. В дебиане (да и rpm-дистрах) не затрутся _конфиги_. Т.е. особые файлы, про которые в метаданных пакета специально отмечено, что пользователь может их менять. Все остальные файлы, включая init-скрипты, большинство пакетных менеджеров перезаписывает без вопросов.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	80. "Второй отчет о развитии системного менеджера systemd"	–1 +/–
	Сообщение от Аноним (??) on 22-Ноя-10, 01:40
	> init-скрипты, большинство пакетных менеджеров перезаписывает без вопросов. В дебиане не перезаписывает.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	103. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от non anon on 22-Ноя-10, 14:50
	> В дебиане не перезаписывает. Во-во dpkg: не удалось обработать параметр /var/cache/apt/archives/ia32-libs_20101117_amd64.deb (--unpack): попытка перезаписать /usr/lib32/libcurl.so.4.2.0, который уже имеется в пакете ia32-libs-workaround-499043 0.0.1+squeeze1 configured to not write apport reports                                       dpkg-deb: подпроцесс вставка завершён по сигналу (Обрыв канала) При обработке следующих пакетов произошли ошибки: /var/cache/apt/archives/ia32-libs_20101117_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Поубивал бы за такие пакетные менеджеры.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	124. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от Олег (??) on 25-Ноя-10, 21:15
	Наткнулся на ту же ошибку при обновлении. Лечению поддается ?
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	127. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от non anon on 26-Ноя-10, 16:34
	>Наткнулся на ту же ошибку при обновлении. >Лечению поддается ? dpkg -r ia32-libs-workaround-499043 && apt-get -f install Флеш на amd64 продолжает нормально работать, видимо, в новой версии workaround уже не нужен.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	47. "Второй отчет о развитии системного менеджера systemd"	+3 +/–
	Сообщение от XoRe (ok) on 21-Ноя-10, 10:51
	> Если у вас нормальный дистрибутив, то, как бы вы ни правили ваши > скрипты, при следующем обновлении они всё равно заменятся на дефолтные, и > ваша система начнёт вести себя совсем по-другому. Иногда нужно не править, а посмотреть. Лично у меня привычка делать "ps ax | grep <name>" после "/etc/init.d/<name> restart" иногда оказывалась очень полезной. Чтобы понять, почему процесс не стартует, нужно знать, как он вызывается. Тут хорошо помогает добавить "-x" в первую строчку скрипта (#!/bin/sh). И то - может понадобиться ещё покопаться, чтобы найти строчку запуска. И только тогда вы увидите искомое сообщение об ошибке. А с бинарными скриптами остается только надеяться и верить)
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	71. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от ZloySergant (ok) on 21-Ноя-10, 23:52
	>> скрипты это большой плюс, если вы хотите иметь контроль над системой > Вы - пользователь LFS? Никто, кроме LFS'ников, не имеет морального права так > говорить. > Если у вас нормальный дистрибутив, то, как бы вы ни правили ваши > скрипты, при следующем обновлении они всё равно заменятся на дефолтные, и > ваша система начнёт вести себя совсем по-другому. Ты, Зин, на грубость нарываисси. Все, Зин, обидеть норовишь   Многие пакетные менеджеры позволяют не переписывать файлы в каталогах, а  оставлять   бэкап;  диффы   показывают,  спрашивая  что   делать  с изменениями.  К примеру,  slackpkg. В  данном случае  все  упирается в используемый инструмент, а не дистрибутив.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	78. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от анон on 22-Ноя-10, 00:29
	>Многие пакетные менеджеры позволяют не переписывать файлы в каталогах, а  оставлять   бэкап;  диффы   показывают,  спрашивая  что   делать  с изменениями.  К примеру,  slackpkg. В  данном случае  все  упирается в используемый инструмент, а не дистрибутив. Вы думаете, это касается всех файлов в пакете, включая исполняемый код, а не только конфигов? Интересно было бы посмотреть, как ваш slackpkg показыват diff бинарника :-)
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	79. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от ZloySergant (ok) on 22-Ноя-10, 01:25
	> Вы думаете, это касается всех файлов в пакете, включая исполняемый код, а > не только конфигов? Можно и так. Благо, скрипты *pkg позволяют такой функционал реализовать. При желании, можно и аналог blacklist'a для отдельных файлов привинтить. > Интересно было бы посмотреть, как ваш slackpkg показыват diff бинарника :-) Молча :)
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	87. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от reinhard (ok) on 22-Ноя-10, 11:35
	> Поттеринг предлагает совершенно другой путь - вместо ковыряния в потрохах скриптов, использовать продуманные программы с гибкими настройками на все случаи жизни. Т.е. как в Windows™? Умный Баллмер^WПоттеринг лучше знает, что нужно пользователю.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	97. "Второй отчет о развитии системного менеджера systemd"	+1 +/–
	Сообщение от non anon on 22-Ноя-10, 14:29
	>Т.е. как в Windows™? Как в Windows™ - это сейчас. Собрались в одном месте толпа индусов и грузовик портвейна, накодили такого, что внутрь глянуть страшно и стыдно, а толпа хомячков подвывает "Rulezzz!". Поттеринг предлагает сделать наконец загрузку по юниксвею - модульно, прозрачно, без костылей, легко настраивается.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	98. "Второй отчет о развитии системного менеджера systemd"	+1 +/–
	Сообщение от develop7 (ok) on 22-Ноя-10, 14:34
	>>Т.е. как в Windows™? > Как в Windows™ - это сейчас. Собрались в одном месте толпа индусов и грузовик портвейна, накодили такого, что внутрь глянуть страшно и стыдно, а толпа хомячков подвывает "Rulezzz!". полуграмотных хомячков. А в остальном — всё так.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	107. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от reinhard (ok) on 22-Ноя-10, 16:58
	В Windows™ загрузка организована шелл-скриптами? Я что-то пропустил? Мне всегда казалось, что там некий бинарный менеджер служб. Насчет прозрачности: что может быть прозрачней, чем Шелл-скрипты? А вот будет ли systemd прозрачным? Мне сомнительно.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	111. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от develop7 (ok) on 22-Ноя-10, 17:09
	> В Windows™ загрузка организована шелл-скриптами? Я что-то пропустил? > Мне всегда казалось, что там некий бинарный менеджер служб. В общем, да — имена служб, «что запускать» и зависимости хранятся в реестре в условно читабельном виде. > Насчет прозрачности: что может быть прозрачней, чем Шелл-скрипты? А вот будет ли systemd прозрачным? Мне сомнительно. Шеллскрипт ещё нужно разобрать. А вот чтобы почитать systemd --dump, не нужно вообще никаких навыков. Ну может немного знать устройство ОС, но это же не проблема, не так ли?
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	100. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от develop7 (ok) on 22-Ноя-10, 14:38
	>> Поттеринг предлагает совершенно другой путь - вместо ковыряния в потрохах скриптов, использовать продуманные программы с гибкими настройками на все случаи жизни. > Умный Баллмер^WПоттеринг лучше знает, что нужно пользователю. Вот именно — пользователю, а не полуграмотному быдлану с админозом головного мозга (взять всё и поделить^W пирисабрать из исходнекаф!11), ниасилившему хотя бы два языка программирования и хотя бы один менеджер пакетов.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	102. "Второй отчет о развитии системного менеджера systemd"	+5 +/–
	Сообщение от non anon on 22-Ноя-10, 14:48
	Вообще, использование скриптов в качестве ключевых компонентов софта очень сильно провоцирует администратора на неправильные решения. Вместо того, чтобы почитать мануал и погуглить, он тупо полезет в скрипт и наворотит там такого... А вменяемому админу в большинстве случаев незачем лезть в скрипт - у него руки достаточно прямые, чтобы сделать все правильным методом.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	108. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от reinhard (ok) on 22-Ноя-10, 17:00
	Как минимум скрипты полезны для изучения того, как оно на самом деле запускается. Корежить скрипты - крайняя мера, я сам этого не люблю, но иногда это оправдано.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	109. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от develop7 (ok) on 22-Ноя-10, 17:05
	> Как минимум скрипты полезны для изучения того, как оно на самом деле запускается. Корежить скрипты - крайняя мера, я сам этого не люблю, но иногда это оправдано. Что мешает качнуть пакетным менеджером исходники и обсмотреться, как оно там работает, до потери пульса?
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	114. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от reinhard (ok) on 22-Ноя-10, 18:00
	Как правило, код на Shell на порядок проще для понимания, чем на С/С++, все-таки уровень выше. Предупреждая вопрос: да, мне приходилось разбирать и тот и другой код.
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	118. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от develop7 (ok) on 23-Ноя-10, 11:12
	> Как правило, код на Shell на порядок проще для понимания, чем на С/С++, все-таки уровень выше. Для «скриптов на C» можно и DSL на хорошо документированных макросах препроцессора придумать. И убить двух зайцев.
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	110. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от develop7 (ok) on 22-Ноя-10, 17:06
	Я имею в виду в случае с systemd придётся поступать так.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	13. "Второй отчет о развитии системного менеджера systemd"	+1 +/–
	Сообщение от анон on 20-Ноя-10, 15:06
	>И без компилятора (который не ставится обычно на production машинах) ничего не поменяешь, я так понимаю. Суровые сибирские админы не пользуются конфигами - они правят дефолтные настройки прямо в коде!
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	15. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от анон on 20-Ноя-10, 15:33
	А ещё они не признают пакетных менеждеров и локальных репозитариев, и всегда вручную грузят сорцы и патчат их с последующим make && make install на каждом из 100 рабочих серверов. Поэтому, когда суровый сибирский админ обновляет конфигурацию apache, сайт проекта лежит полдня - ведь сорцы нужно скачать на каждый сервак!
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	48. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от XoRe (ok) on 21-Ноя-10, 10:54
	> А ещё они не признают пакетных менеждеров и локальных репозитариев, и всегда > вручную грузят сорцы и патчат их с последующим make && make > install на каждом из 100 рабочих серверов. > Поэтому, когда суровый сибирский админ обновляет конфигурацию apache, сайт проекта лежит > полдня - ведь сорцы нужно скачать на каждый сервак! /etc/init.d/apache stop echo "сегодня обнвляем веб сервер!" | mail -s "уведомление" office@company.ru wget http://httpd.apache.org/сырцы ... Так, что ли? =) Вы в курсе, что для того, чтобы сделать make даже админские права не нужны?
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	25. "Второй отчет о развитии системного менеджера systemd"	+1 +/–
	Сообщение от segoon (ok) on 20-Ноя-10, 16:21
	Я уверен, что всегда останется fallback-механизм с поддержкой legacy скриптов.  Иначе будет сложно загнать какой-нибудь маленький самописный демон watcher/wrapper в систему сервисов.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	75. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от анон on 22-Ноя-10, 00:10
	>Я уверен, что всегда останется fallback-механизм с поддержкой legacy скриптов И он там есть. По сути, service unit - это просто запуск некой программы/команды + некоторые дополнительные возможности. Например, можно уже не париться с ручным отслеживаением lock-файла (создавать его при запуске, удалять при установке, проверять при запросе статуса) - этим займётся systemd. Аналогично, можно поручить ему проверку наличия конфига службы (нет конфига - зачем тогда её запускать?), выжидание паузы перед запуском, сохранение PID-файла, помещение программы в chroot, сброс привилегий и т.п. Т.е. systemd выполняет те операции, которые раньше делались специальными скриптовыми велосипедами. Если их убрать, в 99% случаях останется голая команда на запуск демона. А в оставшемся 1% случаев можно воспользоваться, например, штатными хуками ExecStartPre, ExecStartPost, ExecStop, ExecStopPost, ExecReload, засунув в них нужные команды или скрипты.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

3. "Второй отчет о развитии системного менеджера systemd"	–1 +/–
Сообщение от dalco (ok) on 20-Ноя-10, 14:23
Блин, пролетаю... У меня где RAID, где LVM, где LVM поверх RAIDа :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от анон on 20-Ноя-10, 15:02
	> Блин, пролетаю... У меня где RAID, где LVM, где LVM поверх RAIDа > :) Думаю, к выпуску F15 уж это-то точно сделают. Работы там очень немного.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

16. "Второй отчет о развитии системного менеджера systemd"	+1 +/–
Сообщение от Аноним (??) on 20-Ноя-10, 15:36
> Подготовлен написанный на C инструмент, обеспечивающий корректную остановку системы, включая остановку всех процессов, отмонтирование всех файловых систем, отключение всех loopback-устройств и томов Device Mapper (LVM, Multipath, etc.). Все эти операции производятся по тщательно продуманному алгоритму, обеспечивающему их корректное выполнение практически в любой ситуации. Мда. Не могу не вспомнить http://catb.org/esr/writings/unix-koans/ten-thousand.html Потом, скрипты - это прежде всего прозрачность и низкий порог вхождения. Когда любой админ может туда заглянуть, найти ошибку и запостить патч в багзилу. А тут вместо прозрачного скрипта будет чёрный ящик, в который никто не полезет. И который всё равно всё равно вызывает umount, lvm и другие утилиты - так в чём разница с шелл-скриптом? Если скрипт тормозит оттого, что вызывает grep, awk и другие внешние утилиты - значит, давайте думать, как сделать, чтобы скрипты не тормозили. Давайте придумаем, например, новый язык для системных скриптов, который отвечал бы современным требованиям, и решим проблему в корне. А переписывать всё на С - это ну детство же, честное слово. Давайте ещё на ассемблере перепишем, всё ваще будет летать, посоны одобряют.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	17. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от анон on 20-Ноя-10, 15:39
	> Давайте придумаем, например, новый язык для системных скриптов, который отвечал бы > современным требованиям, и решим проблему в корне. Уже придумали. C называется. На нем написаны такие важные "системные скрипты", как, например, ядро ;-)
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	20. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от Аноним (??) on 20-Ноя-10, 15:44
	Напиши на C, пожалуйста, эквивалент curl "http://en.wikipedia.org/wiki/Pipeline_(Unix)" | \ sed 's/[^a-zA-Z ]/ /g' | \ tr 'A-Z ' 'a-z\n' | \ grep '[a-z]' | \ sort -u | \ less
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	23. "Второй отчет о развитии системного менеджера systemd"	+1 +/–
	Сообщение от анон on 20-Ноя-10, 15:52
	> Напиши на C, пожалуйста, эквивалент Только после того, как вы объясните, зачем эти действия нужны при загрузке системы :-)
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	50. "Второй отчет о развитии системного менеджера systemd"	+1 +/–
	Сообщение от XoRe (ok) on 21-Ноя-10, 11:02
	>> Напиши на C, пожалуйста, эквивалент > Только после того, как вы объясните, зачем эти действия нужны при загрузке > системы :-) Ближе к телу - попробуйте переписать на С скрипт /etc/init.d/rc
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	74. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от анон on 21-Ноя-10, 23:57
	> Ближе к телу - попробуйте переписать на С скрипт /etc/init.d/rc Герр Поттеринг как раз это и сделал (добавив плюшек от себя) :-)
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	19. "Второй отчет о развитии системного менеджера systemd"	–3 +/–
	Сообщение от анон on 20-Ноя-10, 15:43
	> Потом, скрипты - это прежде всего прозрачность и низкий порог вхождения. Когда > любой админ может туда заглянуть, найти ошибку и запостить патч в > багзилу. А тут вместо прозрачного скрипта будет чёрный ящик, в который > никто не полезет. Я вообще не понимаю, что вы делаете на современных осях, где и ядро (полностью), и окружение (почти полностью) являются бинарными? Напишите свою ось с ядром на руби, и окружением на руби, и чтобы интерпретатор руби в биос прошивался. И никакого байткода! Те, кому очень важна прозрачность, однозначно выберут вашу систему. А убогие любители скорости останутся в загнивающем бинарном мире.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	51. "Второй отчет о развитии системного менеджера systemd"	+1 +/–
	Сообщение от XoRe (ok) on 21-Ноя-10, 11:05
	> Я вообще не понимаю, что вы делаете на современных осях, где и > ядро (полностью), и окружение (почти полностью) являются бинарными? Не путайте выполнение и контролирование. То же бинарное ядро и бинарное окружение пишут логи в текстовом виде. Для чего? Чтобы было удобнее контролировать (проверять работу и искать причину отказов. Вы же не хотите, чтобы файлы в /var/log были в бинарном виде?
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	57. "Второй отчет о развитии системного менеджера systemd"	+1 +/–
	Сообщение от zerot (ok) on 21-Ноя-10, 13:41
	> Я вообще не понимаю, что вы делаете на современных осях, где и > ядро (полностью), и окружение (почти полностью) являются бинарными? патаму шта мир сложная весчь. Современная ось - сложная система, в которой есть разные решения для разных задач. Что по пишется на Сях или Асме, что то на скриптах, ибо адекватнее. А дальше вопрос привычек, у меня например с 2002 года на работе, дома и т.п. стоит Юникс. Ставился он изначально волевым решением - чтобы разбираться, и переходить на парадигмы форточек и использование оных я согласен только при обоснованной необходимости под конкретные задачи, ибо глюкавое поделие - Так что скрипты на своём месте, а дальше время покажет, главное не вестись на истерию, пусть пена бурлит в стороне
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	21. "Второй отчет о развитии системного менеджера systemd"	+2 +/–
	Сообщение от gaga on 20-Ноя-10, 15:45
	>Давайте придумаем, например, новый язык для системных скриптов, который отвечал бы современным требованиям, и решим проблему в корне. Это полумера, я считаю. Давайте сразу придумаем свой компьютер и свою ОС, которые будут отвечать современным требованиям, и решим проблему в корне.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	37. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от develop7 (ok) on 20-Ноя-10, 22:31
	> А тут вместо прозрачного скрипта будет чёрный ящик, в который никто не полезет. Полезут. Только лазать будут вменяемые люди с опытом разработки ПО, а не носители админоза головного мозга.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

26. "Второй отчет о развитии системного менеджера systemd"	+2 +/–
Сообщение от pavlinux (ok) on 20-Ноя-10, 17:06
Надо сделать ассистента ядра, в виде модуля, который есть нечто иное как конфиг системы. Например сетевушки char const *eth_names[] = {"eth0", "eth1", "ppp0",...}; struct eth_attr {          char *name;          int  negotation;          int  speed;          uint  mac;          char *ip;          char *mask;          ....   } и махонький компилер - kcc (kernel c compiler), там же будут одни константы. А уже сам девайсы, при init_module() будут обращаться к этим структурам и константам, даже не константам, а просто глобальным переменным. Кстати, хороший пример GRUB 2
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	29. "Второй отчет о развитии системного менеджера systemd"	–3 +/–
	Сообщение от Аноним (??) on 20-Ноя-10, 17:44
	А вот несколько другой путь: http://www.calculate-linux.ru/main/ru/templates#%D0...
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	33. "Второй отчет о развитии системного менеджера systemd"	+6 +/–
	Сообщение от User294 (ok) on 20-Ноя-10, 18:00
	> А вот несколько другой путь: > http://www.calculate-linux.ru/main/ru/templates#%D0... Конфиги в XMLнике? Спасибо, но имхо лучше уж тогда сишный код править :)
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	52. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от XoRe (ok) on 21-Ноя-10, 11:06
	> А вот несколько другой путь: > http://www.calculate-linux.ru/main/ru/templates#%D0... Microsoft пошла по этому пути)
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	83. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от www2 (ok) on 22-Ноя-10, 08:22
	Вы это серьёзно? Нет, в самом деле? Я так понимаю, что настоящий юникс умер вместе с настоящими юниксоидами. Это же надо додуматься - компилятор для конфигов! И пример с GRUB 2 - плохой.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	105. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от pavlinux (ok) on 22-Ноя-10, 14:56
	> Это же надо додуматься - компилятор для конфигов! А реестр в венде это ни одно и тоже? :) Собственно можно обойтись и GCC, но уже слышу толпы возмущённых юзеров, "- нафига нам компилятор для работы!!!", по этому и написал - отдельная утиль! * GUI-морда, systgui[qsystgui, gsystgui, ksystgui, xsystgui] - для конфигурации.   Кнопка [ Save ], при нажатии на которую и запускается "компилятор конфигов",   более того, этот компилятор переименуют в systmake, чтоб не пугались.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

28. "Второй отчет о развитии системного менеджера systemd"	+/–
Сообщение от cmp (??) on 20-Ноя-10, 17:33
С одной стороны - зоопарк из кучи инициализационных скриптов давно пора ликвидировать, меняющийся их функционал от дистрибутива к дистрибутиву в купе с дружественностью отдельных проектов к отдельным дистрибутивам же, как и попытки некоторых проектов включить в себя код обслуживающий процессы делает практически невозможным создание системы удовлетворяющей требованиям - простоты, скорости, функциональности и гибкости. Если ни одна из существующих систем не подходит, логично предположить появление еще одной - рассчитанной на удовлетворение исходным критериям. Однако, стоит задуматься, насколько подобное решение будет эффективным, понятно, что для разработчиков Apache написать скрипт для новой системы труда не составит, а даже если они этого не сделают, это сделают разработчики самой системы инициализации, но существует ПО которое уже давно никто не разрабатывает, соответственно кому-то придется создавать новые пакеты со старым софтом для новой системы, более того кто-то должен добавлять поддержку новой системы в новые проекты, учитывая, что администрации некоторых из них не удосуживаются выложить даже архивы с исходниками релизов отписываясь ссылкой на git-репозитарии, возникает вопрос кто этим будет заниматься, в контексте жирных корпоративных клиентов - это будет сам redhat, частично комьюнити. Но в полном объеме никто этого не сделает, кроме конечного админа (если он не забьет), разумеется будут оставленны всевозможные способы выполнения задачи в режиме совместимости с другими системами - для ленивых админов/пользователей и как результат вместо первоначального зоопарка мы получим зоопарк с еще одним питомцем. Очевидно надо ввести уровень абстракции что-то вроде HAL и не hald от которого некоторые дистрибутивы успели отказаться, а что-то другое, что позволит изголяться над системой как угодно на радость красноглазикам, писать сценарии загрузки для корпоративных клиентов и тд, В линуксе уже есть рабочие аналоги подобных решений, в частности sysfs; удобная, функциональная и легковесная,.. Если уж речь идет об управлении процессами, то заниматься этим должен некоторый процесс, соответственно демон, dbus сомнительная кандидатура, хотя бы потому, что на пару с hald был отвергнут. И смотреть тут надо на так нелюбимую некоторыми винду и ее системами управления процессами, устройствами и событиями. Короче говоря в нынешнем виде этот systemd костыль не меньший чем скрипты,
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	31. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от Вирус on 20-Ноя-10, 17:55
	Грядет очередной зоопарк как и с upstart, где часть скриптов в /etc/init , а та часть , которую не допилили/забили лежит в /etc/init.d
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	42. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от Etch on 21-Ноя-10, 07:23
	Не переживайте, постепенно все скрипты перепишут. Когда всё устаканится, станет окончательно понятно какая из систем инициализации наиболее полно соответствует всем требованиям современного мира, тогда и все скрипты под неё перепишут.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	53. "Второй отчет о развитии системного менеджера systemd"	+2 +/–
	Сообщение от XoRe (ok) on 21-Ноя-10, 11:13
	> С одной стороны - зоопарк из кучи инициализационных скриптов давно пора ликвидировать, > меняющийся их функционал от дистрибутива к дистрибутиву в купе с дружественностью > отдельных проектов к отдельным дистрибутивам же, как и попытки некоторых проектов > включить в себя код обслуживающий процессы делает практически невозможным создание системы > удовлетворяющей требованиям - простоты, скорости, функциональности и гибкости. > Если ни одна из существующих систем не подходит, логично предположить появление еще > одной - рассчитанной на удовлетворение исходным критериям. Однако, стоит задуматься, Вопрос "на подумать": "не подходит" кому? Операционкам, или пользователям? Операционки с этих "неудобных" скриптов уже десятки лет стартуют. Им хватает и функциональности, и гибкости. А то, что для пользователей это "некрасивая реализация" - это другой вопрос. К вопросу "работает/не работает" он не относится.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	54. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от Аноним (??) on 21-Ноя-10, 11:28
	>[оверквотинг удален] > которого некоторые дистрибутивы успели отказаться, а что-то другое, что позволит изголяться > над системой как угодно на радость красноглазикам, писать сценарии загрузки для > корпоративных клиентов и тд, В линуксе уже есть рабочие аналоги подобных > решений, в частности sysfs; удобная, функциональная и легковесная,.. Если уж речь > идет об управлении процессами, то заниматься этим должен некоторый процесс, соответственно > демон, dbus сомнительная кандидатура, хотя бы потому, что на пару с > hald был отвергнут. > И смотреть тут надо на так нелюбимую некоторыми винду и ее системами > управления процессами, устройствами и событиями. > Короче говоря в нынешнем виде этот systemd костыль не меньший чем скрипты, Какой дивный поток сознания!
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	77. "Второй отчет о развитии системного менеджера systemd"	+/–
	Сообщение от анон on 22-Ноя-10, 00:22
	> Если уж речь идет об управлении процессами, то заниматься этим должен некоторый процесс, соответственно демон, dbus сомнительная кандидатура, хотя бы потому, что на пару с hald был отвергнут. И смотреть тут надо на так нелюбимую некоторыми винду и ее системами > управления процессами, устройствами и событиями. Вы не поверите, но systemd как раз и есть такой демон. Но, судя по тому, что вы путаете функции dbus, hald и sysfs, вы все-таки не поверите :`(
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

49. "Второй отчет о развитии системного менеджера systemd"	+4 +/–
Сообщение от DFX (ok) on 21-Ноя-10, 10:56
при первом отчёте это сильно выглядело как ещё одна поделка аля upstart, но тут уже впечатляет. надеюсь обороты авторы не сбавят. одолел этот беспорядок в init'е. такие простые, казалось бы, вещи, как нормальное укакошивание пользовательских процессов до отмонтирования и гарантия отмонтирования без затыков вообще (особенно в системах с кучей loop'ов и bind'ов) до сих нигде, вроде, и не сделали. PS: "Если уж речь идет об управлении процессами, то заниматься этим должен некоторый процесс, соответственно демон, dbus сомнительная кандидатура, хотя бы потому, что на пару с hald был отвергнут. И смотреть тут надо на так нелюбимую некоторыми винду и ее системами управления процессами, устройствами и событиями." <-- автор, ты с ума рехнулся ? это в винде-то управление устройствами и отправка событий пример для GNU/Linux'ов ? и кто это и где "отверг" dbus ? udev и dbus сейчас основные инструменты отлавливания и пересылки событий у freedesktop (читай: Гном и КДЕ) :\ systemd вообще вокруг dbus построен. и от hald не "некоторые дистрибтивы успели отказаться", а разработчики X выпилили его из xorg-server, заменив hal-config на udev-config... он больше нигде и не нужен. все, кто его ещё не выпилил - выпилят.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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