The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

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

"Второй отчет о развитии системного менеджера systemd"  +/
Сообщение от opennews (ok) on 20-Ноя-10, 14:08 
Леннарт Поттеринг, возглавляющий разработку перспективной системы инициализации systemd (https://www.opennet.ru/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
Новость: https://www.opennet.ru/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 email(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 email(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 email(??) 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 email(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 email(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 email(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 email(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 email(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 email(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 email(ok) on 22-Ноя-10, 14:54 
мистер анон, гадить в разговоре, а дальше делать вид что не гадили и ждать продолжения диалога не проканает (см. прежние посты). сказать что мне в принципе есть, но вас уже нет
Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

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

116. "Второй отчет о развитии системного менеджера systemd"  +/
Сообщение от Michael Shigorin email(ok) on 23-Ноя-10, 09:42 
> chattr +i имя_файла

Об это потом споткнётся обновление -- станет болтаться минимум один пакет, который каждый раз будет пытаться обновиться и неудачно.

Если что-либо настолько мешает жить, обычно лучше его снести.

> Для этого есть штатные механизмы

Это если он %config(noreplace), в чём я лично не уверен (проверить сейчас неудобно, gprs).

PS: а вообще Леннарт будто оправился от пульса и опять в конструктивное русло :)

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

120. "Второй отчет о развитии системного менеджера systemd"  –1 +/
Сообщение от zerot email(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 email(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 email(ok) on 21-Ноя-10, 22:48 
> Можно, конечно, развить эту идею дальше, и заблокировать скрипт от изменений (например,
> через атрибуты фс). Тогда на середние апдейта ВНЕЗАПНО упадёт пакетный менеджер,
> и при следующей перезагрузке система может вообще не загрузиться. Классно!

эта адская картина не обязательно соответствует действительности, даже если говорить про апдейт, а не загрузку системы. Даже зачастую не соответствует. И потом, вы же на продакшене (хоть сервера хоть workstation) не обновляетесь, не пройдя обновление на тестовой среде ? Домашняя машина у вас наверняка рядом с болванкой LiveCD, чтобы при отказе загрузки восстановиться руками. Да и смотрите наверняка, какие пакеты будут обновляться.  Батюшка поп, зачем прихожан пугаете ?

> Дорогой zerot, апологет ректальной тонзиллэктомии! You made my day, thank you very
> much!

да, как мало вам нужно для активации проявления следов высшей нервной деятельности, сдобренной знаниями этикета, околомедицинской терминологии и какого то :) нерусского языка

Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

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

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

123. "Второй отчет о развитии системного менеджера systemd"  +/
Сообщение от Michael Shigorin email(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 email(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 email(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 email(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 email(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 email(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 email(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 email(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 email(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 email(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 | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру