LINUX.ORG.RU

Systemd за и против (тихо мирно и спокойно)

 


1

3

Собственно я инертен, почитал про этот Systemd немного так вроде годная вещь при определённом подходе, или я не прав? Единственный дурдом как я понял это снос привычных скриптов запуска и тп., или я не прав? Вообщем объективно разжевать можете, желательно с реальными примерами, а не с обсираниями восхищениями с потолка.

★★★★★

1. Да, оно быстрее. Все происходит максимально параллельно. 2. Не замечал необходимости ничего сносить. Поставил systemd, initscripts уже просто не нужны, удалил их. 3. Через systemctl очень удобно посмотреть, что запущено, а что-нет. 4. Через эту же программу легко добавляются/удаляются/запускаются/останавливаются/перезагружаются юниты. Одни плюсы.

Vekt
()

У него один минус - оно не так, как раньше. И это мнение имеет право на жизнь, потому что привычки значат очень многое. Но плюс в виде унификации всех дистрибутивов перекрывает этот минус с лихвой.

vurdalak ★★★★★
()

Оно следит за процессами, которые запустило. В отличие от всех остальных систем инициализации, systemd не только запускает демоны один раз при загрузке, а и позволяет определять, запустились ли они, и узнаёт, когда они падают. Использование cgroups для слежения за демонами позволяет надёжно завершить все процессы, порождённые демоном, при необходимости остановить демон.

gentoo_root ★★★★★
()

Да ничем он не плох, шило на мыло в сущности. Но пока на кошках арчефедорамышах не потренируются, ставить его просто рано.

Serg5Markov
()

Давай объективнее, без «годная вещь». Плюсы и минусы. Что ж, я скажу первым - система с System D не загружается, если /usr на отдельном разделе.

А если без объективности - мне автор не нравится.

ZenitharChampion ★★★★★
()
Ответ на: комментарий от Serg5Markov

Я так и думал, что будет аргумент «не нужно!». Читая старые темы 2004-2005 годов я несколько раз видел упоминания людей об отдельном /usr на своём компьютере. Почему бы нет? Но нет же - нужно понапридумывать кучу условностей. Там - запускать приложения только для такого-то DE, здесь - патчить приложения для добавления поддержки нового звукового сервера. А теперь ещё и /usr нельзя выносить на отдельный раздел! Да голова гудит от всего того, что нужно отключать или удалять сразу после установки системы!

ZenitharChampion ★★★★★
()

Вроде можно же управлять init-скриптами: systemctl enable foo.service, не?

BMX ★★☆
()
Ответ на: комментарий от ZenitharChampion

Да нет :-) сделать, конечно, можно почти все, и потом говорить что «это под мое не подходит», но зачем делать то ? Какая сейчас объективная необходимость обязательно выносить usr, иначе никак ?
Да и вообще :-) я скорее согласен с Федоручком, это поделие нужно в основном для убыстрения загрузки, но зачем само по себе нужно это убыстрение на 5 сек, при том что ломается почти все, непонятно.

Serg5Markov
()

Оно хуже потому что вносит явно не нужные изменения иерархии в фс.

Оно лучше потому что: быстрее и вообще в целом оптимальнее подходит к инициализации, использует cgroups (который давно в ведре, но реально пользы почти не приносит, а штука очень годная), полноценно следит за демонами, файлы юнитов куда как симпатичнее традиционных init скриптов в любом дистре и многое другое.

Я не использую systemd потому что в gentoo его не ахти как годно впилили, а openrc меня вполне устраивает, пусть и сливает по ряду показателей.

erfea ★★★★★
()
Ответ на: комментарий от juk4windows

против раз
против два

O_O И чем же, интересно, принципиально отличаются vt1 и vt7? Ленарту лень выкинуть захардкоженную циферку, что ли?

Cancellor ★★★★☆
()

Представляешь? Мне вообще плевать - систем - е или - d. Лишь бы работало.

nihil ★★★★★
()
Ответ на: комментарий от Cancellor

Без понятия, лично с ним после таких ответов желания иметь дело нет вообще.

Я хочу видеть сообщения от ядра и загрузки после загрузки, а вот Леннарт сказал зырить на X server и точка.

juk4windows
()

+: быстрее
-: сложнее (вместо одного загрузочного скрипта — 10)
+: более современная
-: пока ненадежная.

Сейчас использую Fedora 17 с systemd и slackware, и честно сказать, ламповая система инициализации BSD нравится больше .

comp00 ★★★★
()
Ответ на: комментарий от erfea

> Оно хуже потому что вносит явно не нужные изменения иерархии в фс.

Может, пришло время сделать форк? Как невовремя Кон Коливас устроился на работу - он ведь изучил планировщик ядра Linux и сделал свой, а потом когда вышел CFS, изучил и его и подредактировал его, при этом много что убрал. Вот и ненужные изменения кто бы убрал, оставляя только хорошие качества!

ZenitharChampion ★★★★★
()
Ответ на: комментарий от ZenitharChampion

Может, пришло время сделать форк?

Сделай, чо.

erfea ★★★★★
()
Ответ на: комментарий от ZenitharChampion

система с System D не загружается, если /usr на отдельном разделе

Я в шоке немного , система инициализации и слежения за процессами должна быть гибка как резинка, а тут ещё дополнительные ограничения появляются, тут то нельзя тут сё нельзя ,раньше радовались что каждую директорию можно на отдельные винты вынести которые находятся в разных точках планеты и соединены через сеть, и на тебе. Можно многое простить но не ограничения ради 5 секунд экономии на загрузке.

Dron ★★★★★
() автор топика
Ответ на: комментарий от ZenitharChampion

Странно. ИМХО они хотят сделать /usr отдельным разделом по умолчанию. Потому и переносят /bin в /usr/bin и т.д. Т.е. текущая ситуация временная.

А если без объективности - мне автор не нравится.

ИМХО у РедХата разные требования к качеству десктопного софта, до которого ему практически нет дела и системы инициализации, от которой зависит^w будет зависеть их интерпрайз. Даде если пишет его один и тот же человек.

at ★★
()
Ответ на: комментарий от Kor03d

Неадекватов все равно больше.

Спору нет есть они, их много.

лукоморье

http://lurkmore.to/

Dron ★★★★★
() автор топика
Ответ на: комментарий от Dron

не понял. чего второй на vt8 уже не получится запустить?

fuxter
()

загрузка за семь секунд.

$ sudo rc.d list
Password: 
[STARTED][AUTO] acpid
[STARTED][AUTO] alsa
[STARTED][AUTO] avahi-daemon
[STOPPED][    ] avahi-dnsconfd
[STOPPED][    ] couchdb
[STARTED][AUTO] crond
[STOPPED][    ] cupsd
[STARTED][AUTO] dbus
[STOPPED][    ] dhcp4
[STOPPED][    ] dhcp6
[STOPPED][    ] dnsmasq
[STOPPED][    ] ftpd
[STOPPED][    ] git-daemon
[STOPPED][    ] gpm
[STOPPED][    ] hwclock
[STOPPED][    ] irexecd
[STOPPED][    ] krb5-kadmind
[STOPPED][    ] krb5-kdc
[STOPPED][    ] krb5-kpropd
[STOPPED][    ] lastfmsubmitd
[STOPPED][    ] lastmp
[STOPPED][    ] lircd
[STOPPED][    ] lircmd
[STOPPED][    ] mdadm
[STOPPED][    ] memcached
[STOPPED][    ] net-auto-wired
[STOPPED][    ] net-auto-wireless
[STOPPED][    ] netfs
[STOPPED][    ] netfs_start
[STOPPED][    ] netfs_stop
[STARTED][AUTO] net-profiles
[STOPPED][    ] net-rename
[STOPPED][    ] network
[STOPPED][    ] nfs-common
[STOPPED][    ] nfs-server
[STOPPED][    ] nginx
[STOPPED][    ] nscd
[STARTED][AUTO] openntpd
[STARTED][AUTO] postfix
[STOPPED][    ] ppp
[STOPPED][    ] rpcbind
[STOPPED][    ] rsyncd
[STOPPED][    ] slpd
[STOPPED][    ] snmpd
[STARTED][AUTO] sshd
[STOPPED][    ] svnserve
[STARTED][AUTO] syslog-ng
[STOPPED][    ] timidity++
ну и зачем мне системД?

fuxter
()

чтобы не удваивать тему дальше читать не буду.

единственный минус системд в том что она ещё не готова, но в опенсурсе нельзя просто так взять и не показать недоделанную работу идиотам(с)

Thero ★★★★★
()

У него один минус. Он не нужен. :)

Если серьёзно, то слишком мало(для меня ноль) systemd даёт пользы, ломая при этом слишком многое. Что за крики про скорость загрузки, я не знаю, у меня дольше всего грузится DE, а не sysvinit/openrc. А серверы я вообще редко бутаю. Юниты может кому и проще, но особой практической пользы в них я не вижу. Отслеживание состояния сервисов видится мне сомнительной фичей, потому как это, имхо, дело каждого отдельно взятого сервиса. И если у меня какой-нибудь там, bind, к примеру, будет падать раз в полчаса, то надо не автоподнималку к нему прикручивать, а искать и устранять причину падений. То же касается и останова сервиса. Не инит должен останавливать какой-нибудь мегасервер с кучей процессов и отслеживать его детей, а сам мегасервер.

Итого. Ломаем отлаженную систему, не принося реальной пользы. Т.е. как всегда оно бывает у Поттеринга. Сама идея того, что запутанные скрипты в загрузке не есть хорошо, неплоха, но реализация отвратительна.

//offtop: и я так до сих пор и не понял, почему вместо того, чтобы фиксить udev для работы с отдельным /usr'ом, явные баги объявляются фичей.

shell-script ★★★★★
()

Против. (Копипаста от анона)

1) Politics: The way that systemd is being pushed is rather unfriendly. The “our way or the highway” approach is disconcerting and unhelpful to a community effort. Especially when one of the main developers uses it as a platform to trash other distributions. Not to mention the absorption of a core project like udev with the intention of deprecating it for use with any other init system.

2) Philosophy: Systemd throws away a lot of unix tradition. Not only with getting rid of shell scripts for initialization, but with it’s lack of a modular structure. Sure udev is kind of separate for now, but that’s unlikely to be the case going forward. journald is inextricable from systemd as well.

3) Binary Logging Formats: Journald is not only inextricable from systemd, but it’s binary logging format is highly contentious. Not to mention poorly documented. The reasons for plain text logs are numerous. The reasons for a new binary logging format are currently few and desktop oriented to say the least.

4) Dependencies: Not every system needs dbus and having it as yet another inextricable part of systemd is troublesome.

5) Lennart: I don’t think it’s a fair argument to dislike something just because someone in particular wrote it, but Lennart certainly doesn’t do himself any favors by being smug and dismissive of other people’s concerns and opinions constantly.

wq
()
Ответ на: комментарий от wq

Краткий перевод.

1. Его слишком форсят.

2. Не юниксвейно.

3. Бинарные логи.

4. Зависимости. Не все хотят в зависимости dbus.

5. Леннарт

wq
()

За (из отзывов сторонников systemd)

1. Быстрее грузится!!111 Параллелизация

2. следит за демонами. управляет ими. cgroups

3. юниты вместо init скриптов

4. RedHat плохого не посоветует. Все вы будете с systemd!

5. Модернизация, инновация

wq
()
Ответ на: комментарий от gentoo_root

Оно следит за процессами, которые запустило. В отличие от всех остальных систем инициализации, systemd не только запускает демоны один раз при загрузке, а и позволяет определять, запустились ли они, и узнаёт, когда они падают. Использование cgroups для слежения за демонами позволяет надёжно завершить все процессы, порождённые демоном, при необходимости остановить демон.

И делает это КРИВО:

[skip]
В ДЦ вырубили питание, и после ребута postgresql не поднялся. Причем systemd какие-то не понятные ошибки сыпал и отказывался его запускать, полечилось через disable/enable сервиса

maxcom ***** (15.08.2012 19:59:30)

sergv
()
Ответ на: комментарий от wq

Lennart

Как бы намекает, что недолюбливающие систему д, мягко говоря, не вполне объективны.

vurdalak ★★★★★
()

Лично я не заметил разницы.

mopsene ★★★
()

Lennart Poettering is an asshole.

Deleted
()
Ответ на: комментарий от Serg5Markov

Это наблюдение по количеству знакомых слаководов. У меня их нет. Пользователи почти всех дистрибутивов есть, кроме слаки.

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

ну прогуляйся на дистроватч
.. не говоря уже о том что это в первую очередь характеризует не слаку :-))

Serg5Markov
()
Ответ на: комментарий от lazyklimm

судя по всему иксы могут быть только на первом виртуальном терминале

у меня на седьмом.
правда, без кмс и на невидии.

pekmop1024 ★★★★★
()
Ответ на: комментарий от shell-script

Отслеживание состояния сервисов видится мне сомнительной фичей, потому как это, имхо, дело каждого отдельно взятого сервиса.

Это каким образом упавший демон должен сам себя поднять?

thesis ★★★★★
()

Да отличное поделие, в теории. Только учить лень. Олдфаги привыкли к тому, что люниксы всегда были примитивными как кирпич, вот и орут, когда нужно что-то новое выучить. Я и сам ору.

thesis ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.