ок, я поставил оба пакета. Система заработала, есть БТ и вайфай. Но черт возьми, очень неуютно не понимать, как оно работает и как этим управлять (

Поттерингу виднее, что уютно, а что нет. ;)
А вообще, говорят, где-то есть официальный сайт с документацией, где подробно расписано как писать костыли^Wправила для systemd. Сам я не пробовал и, надеюсь, никогда в нынешнем его виде и не попробую.

Оно вам надо? С основной задачей — распараллеливанием загрузки — оно не справляется, upstart делает systemd на моём компе в два счёта.

у меня как раз справляется. После строчек, когда стартует ядро, появляется строчка логина. Сразу. Если initramfs убрать, то старт системы на моем нетбуке сократится до 2-3 секунд. У меня нетбук + SSD.

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

Upstart у меня справляется за 40 секунд, systemd - за минуту.

Но это ведь проблема либо настроек (зависит от вас), либо реализации (т.е. теоретически временная), а не самой идеи? Я ничего не настраивал, просто поставил 3 пакета - и с ck-ядром из реп оно у меня стартует молниеносно.

Насчет upstart я не интересовался, с подозрением отношусь ко всему, что продвигается Убунтой.
С какого-то момента, когда Убунту выросла и приобрела немалый вес в linux-сообществе, её создатели объявили всё, что они делают, мейнстримом. И начали совершать "революции", пилить wayland'ы и unity, точить интерфейс под планшеты с сенсорным вводом....
Я в виду имел такой "мейнстрим", пусть лучше уж systemd становится стандартом, чем контролируемая не совсем вменяемыми людьми upstart. Мнение сугубо моё личное и "политическое", с технической точки зрения systemd и upstart я не сравнивал.

Меня религиозный аспект и политические аспекты мало интересовали. Сравнивалась бунта после N обновлений дистра и свежая почти голая зузя.

нетбук на E-350 + SSD Vertex2

Разберусь, как systemd подружить с командой xinit и consolekit - померяю запуск в сумме с иксами (наверное)

Стационарный:

По systemd я полностью разделяю позиции Alv и xandry.

Какая идея, если не секрет?
И что делает systemd, чего не умеет init или там openrc? И почему, до появления systemd не появлялось проблемы отдельного /usr на 99% систем, а теперь из-за каких-то bluetooth-клавиатур и systemd собираются объединять все разделы в одну файлопомойку и на исправление приводящей к этому ошибки udev забили?
Да, а как в systemd мне ручками дописывать свои условия в стартовые конфиги?

https://fedoraproject.org/wiki/Systemd

слово "идея" собирательное.
разумно звучат вещи, описанные (например) тут:
http://tux-the-penguin.blogspot.com/2010/09/systemd.html

Я читал и это, и ссылку, приведённую dront78, но там ответов на мои вопросы. Я вижу много слов "новый, распарралеливание, ускорение, упрощение" и т.д. А на деле то, что он новый, толку не даёт, параллельная загрузка есть и в init'е, и в upstart, и в openrc. Ускорение загрузки? На ноуте у меня всё упирается в слабый проц и медленный диск и ускорение в две секунды за счёт того, что оно бинарное, а не скриптовое мне погоды не сыграет, на десктопе сама отработка openrc занимает какие-то секунды а основную часть времени занимает kde, серверы я не перезагружаю или перезагружаю очень редко. Упрощение? Вместо логичных, простых и понятных скриптов, которые можно быстро попроваить, можно добавить свои условия, можно взять и с нуля мгновенно написать для своего демона стартовый скрипт. И при этом не надо городить ничего лишнего. Любой админ и так знает, как писать скрипты, так что сможет это сделать моментально. А неадминам пофиг, что там за система инициализации - они этого не различают и не замечают.
Поэтому повторюсь. Что за идея? Конкретно и понятно. Потому что я не понимаю, зачем нужен этот бинарный велосипед с квадратными колёсами.

Ответов на все вопросы у меня нет (были бы - вообще бы вопросов тут не задавал, а наоборот - отвечал бы на них). Есть только собственное мнение.

На дворе 2012 год. На линукс-системах, как и 15 лет назад, запуск сервисов происходит с использованием shell-скриптов и различных awk, grep и прочего, что в эти скрипты понапихано - и получается по 100500 вызовов каждой команды за один запуск системы.

Мощность современных процессоров совершенно дурная в сравнении с таковыми 10-летней давности, но современные linux-дистры имеют наглость грузиться так, как будто и не было этих 10 лет.

Linux все больше проникает в сегмент десктопов, и разумно ожидать от него соответствия запросам времени. Если на серверной системе скриптовая инициализация является изящным решением (редкие перезапуски демонов и самого сервера, производительность не важна, зато прозрачность и легкость администрирования), то у десктопных пользователей совсем другие требования.

Я включаю-выключаю свой нетбук часто. Очень часто. Попользовался - вырубил, чтобы батарею экономить. Я технарь по образу мышления, и меня раздражает осознание того, что время загрузки системы уходит на обработку башем скриптов инициализации. С гибернацией у меня не сложилось: помимо регулярных косяков с разными прогами после включения, под это дело надо выделить 4 Гб под SWAP на моем 40 Гб SSD. И эти 4 Гб нельзя в любую секунду занять под другие нужды - надо лезть в редактор разделов, убивать SWAP-раздел и расширять какой-нибудь другой. Это не говоря об износе SSD. Поэтому мне надо мгновенную загрузку и желательно - такое же выключение.

Под такие запросы подходит бинарная система инициализации. Честно говоря, мне не важно, как она будет называться - лишь бы она делала свое дело, делала его хорошо и была бы стандартом для нескольких популярных дистров.

Я пробовал init-ng и ещё что-то, как-то оно косячило и не прижилось на уровне стандартной комплектации какого-либо дистра. Поэтому я просто ждал, когда же начнут такую систему развивать и продвигать. Возлагаю свои надежды на systemd - раз уж именно за нее взялись разработчики.

При этом на сервачке дома нахрен она не сдалась - даже не думаю ставить. Это сервер и он работает, и я знаю что в нем и как работает. Но сейчас, нахватавшись шишек и знаний после установки systemd на основной мой комп, когда-нибудь я без проблем переведу на него сервер, и он к тому моменту будет гораздо стабильнее и фичастей.

Т.е. получается две связанные плюшки, обещанные в systemd.
1. Зачем в 21-ом веке скрипты? Даёшь бинарник!
2. Благодаря п.1 скорость загрузки больше.

Так вот сам по себе бинарный демон - это не преимущество. Выбор между бинарником и скриптом должен делаться в зависимости от требований. А теперь давайте посмотрим на требования. Ну, например, загрузку sshd. Первое, что в голову пришло. Смотрим в тело скрипты и не видим ни одного awk, ни одного sed или grep. Открываем тут же рестарт того же sshd в debian(SysV). Видим один grep. Что же составляет основное тело скрипта что в первом, что во втором случае? Правильно. Тесты, есть ли нужные директории, запущены ли необходимые сетевые интерфейсы, проверки встроенными утилитами демона, правилен ли конфиг, проверки, нудны ли новые ключи и в этом случае их регенирация и т.д. и т.п. Т.е. работа с винтом и работа встроенных средств запускаемого демона. Никаких sed'ов с awk'ами и никаких мегаконструкций. И systemd тоже должен будет это делать. И вот например, я не уверен, что [-d /path/to/dir ] работает быстрее, чем какой-нибудь вызов внутри systemd, потому что скорость подобных проверок зависит не от проги, а от винта, загруженности ядра, файловой системы, дефрагментации и т.д. Утилиты демона опять же отрабатывают всегда с одной и той же скоростью, вне зависимости от того, дёрнул эту утилиту скрипт или дёрнул её systemd. Что мы получаем в итоге? Один grep. Несколько сэкономленных миллисекунд. В итоге, как я говорил до этого на машине с кучей сервисов и всего остального мы при использовании systemd получаем прирост скорости загрузки в несколько секунд. Как говорят очевидцы, которые пробовали и которым я верю - не больше пяти на среднестатистическом десктопе, а обычно около одной-двух. А в некоторых случаях ещё и наоборот отставание, потому как некоторые демоны используют для запуска (ВНЕЗАПНО) bash-скрипты. Прямо внутри у себя. И systemd тратит время на дёрганье оболочки. Но это так, редкость.
Получается, из-за пары секунд мы переписываем всё. Ладно, скажет кто-то. Две - не две, но надо исправить. Согласен. После нашего беглого анализа мы видим, что в дебиане есть grep. Когда-то такая же проблема встала перед разработчиками bash. В скриптах вызывать внешнюю утилиту было долго и они встроили функционал grep в оболочку. Надо подумать, провести тесты и посмотреть, может проще добавить в dash, используемый в debian'е минимальный функционал grep'а(как скорее всего сделано в gentoo), чем переписывать всю систему инициализации? Может ещё есть какие-то проблемы, но они не озвучены пока.
Вот и получается, что вся аргументация защитников systemd сводится к "скрипты зло, потому что они скрипты" или "скрипты, это прошлый век, поэтому надо срочно бинарный блоб". Ага. И логи бинарные, прибитые гвоздями к systemd(см. journald от того же автора). Вот и получается отличная и юзабельная система, где пользователь ради двух секунд загрузки получает монструозный комбайн вместо да, старого, да простого, но, блин, работающего по принципу KISS набора проверенных команд. И если сейчас в линуксах при загрузке поломается какая-то часть, её можно починить отдельно. Если что-то поломается в systemd или любом его компоненте, систему загрузить будет невозможно. И получим мы тёплый ламповый BSOD и переустановку системы на каждый чих.
Это не преувеличение. Я не зря несколько раз спрашивал о идее. Так вот эту идею озвучивал товарищ Поттеринг. Суть в том, что ему не нравится то, что сейчас в линуксах всё разрознено - кто-то скрипты себе пишет, кто-то журналы свои ведёт, кто-то конфиги использует, а кто-то опции командной строки. И он решил, что надо сконструировать единый монолит(не стандарт, нет, а именно монолит), который будет отвечать за всё. И конфиги читать, и утилиты дёргать, и логи писать, и команды отдавать. К чёрту unix-way. К чёрту простоту и прозрачность. Поэтому, имхо, systemd - это не решение. Это помеха нормальной работе GNU/Linux. Это резкий поворот в сторону дорожки под названием Windows, с нашей пусть не скоростной и тернистой, но таки двигающейся вперёд дороги UNIX. Только у мелкомягких есть деньги, чтобы тратить их на рекламу и лоббирование своего софта, каким бы кривым он не был, а вот у нас, opensource'ников нет, так что на их поле мы проиграем...
И да. Не надо говорить, что Linux сейчас грузится как и много лет назад, долго и нужно. я проверял на ноуте Fedora 13 vs Windows Vista(здесь пост был с историей) - не сравнить. На своём компе мне недавно принесли винт с виндой, данные с него вытянуть. Gentoo vs Windows 7, вообще небо и земля. Давно когда-то держал Debian Lenny и Windows XP. Догадайся, кто быстрее грузился? Это до приглашения залогиниться. А я уже выше говорил, что на современных системах большую часть времени съедает загрузка DE. И тут systemd не поможет.
Но что больше всего меня не радует, так это то, что systemd не предлагая ничего нового, ломает старое. Когда выяснилось, что systemd не умеет грузиться на системах с отдельным /usr/ стали копать и выяснили, что это из-за udev, который что-то оттуда тянет(специфические ресурсы для всяких блютузов и т.п.). Только вот openrc почему успевал сначала дёрнуть udev, чтобы получить список винтов, примонтировать разделы, а потом уже параллельно дёргать udev для голубого зуба и загружать остальные демоны. Что же это за система загрузки будущего такая, которая не может сделать того, что могут "устаревшие скрипты"? И что делают дальше? Правильно, решают, что раз systemd не может, надо отказаться от использования отдельных разделов, не исправлять ошибки в udev и вообще, чего уж там мелочиться, объединить /usr/(bin|sbin) с корневыми.
Я посмотрю через несколько лет на то, во что превратится systemd и всё, что с ним связано (journald и что там ещё задумано) и посмеюсь с вашего Enterprise Desktop Linux, который мало чем будет отличаться от какой-нибудь Windows 9 Ultimate. А сам буду пользоваться проверенным debian'ом и гентой, которые, к счастью, на такую фигню не ведутся.

Люблю когда аргументированно)

Доводы отличные, принимаются, и точка зрения мне близка. Я надеюсь, что Арч тоже будет поддерживать олдскул.

Возразить могу только по мелочи:

На неназываемом была статья об историческом прошлом rootfs, вот цитата:



Так что объединение /usr и корня не такая уж идиотская мысль))

Ага, читал это письмо(это не статья, а ответ в почтовой рассылке busybox). Но со временем всё изменилось. И это разделение оказалось удобным. Ведь сейчас никто не будет спорить, что /home всё-таки лучше держать отдельным разделом? На PDP-11 у них небыло гигабайтов пользовательских данных, которые жалко потерять. А так же у них не было большой системы со множеством баз данных (а для этого ой как полезно держать отдельный /var) и некритичного для базовой системы софта с его документацией и ресурсами(для чего сейчас используется /usr/). В итоге получается, что в корне у нас есть минимальная система, которую в случае чего можно использовать для восстановления остальной. Да, сейчас компы умеют с флешек грузить и можно таскать с собой rescuecd, но я не хочу из-за того, что кому-то не понравились разные разделы, терять лишний шанс спасти систему в случае чего. Ну и банальное разграничение может избавить от проблем переполнения. Я постоянно делаю отдельный /tmp, отдельный /var и отдельный /usr. /tmp, чтобы какой-нибудь mc, открывая архив или копируя по ftp не завесил мне всю систему(он туда предварительно копирует данные, а только потом переносит их в место назначение, а если tmp вместе с корнем, место заканчивается, и системе не хватает пространства для работы остальных сервисов). /var, чтобы какая-нибудь внезапно распухшая база данных или какой-нибудь лог не сделал того же самого, что mc из предыдущего примера. /usr, чтобы ошибка в пакетном менеджере не сделала этого. Все эти примеры я опробовал на своей шкуре(с /usr'ом, правда, не именно пакетный менеджер виноват был, а самописный скрипт, его вызывающий, но суть та же). И аргумент о том, что сейчас винты такие, что можно этого не бояться, не катят. Неосторожно запущенный лог мускля с фиксацией запросов на более-менее нагруженной системе съедает гигабайты места в считанные секунды. Понятно, что нужно быть внимательным, но зачем от лишней подстраховки отказываться?
Ну и как я говорил, изначально это письмо в рассылке busybox. Согласен, у них там такое разделение не нужно и тянется по истории. Им достаточно ro корня и /tmp монтирующегося в rw. Вполне верю, что такого разделения не нужно было в славные времена PDP-11. Но сейчас оно необходимо. Так что, имхо, мысль таки идиотская. ;)

вообще то там на счет /usr целая статья почему он не нужен ;) и блютус тут не особо причем, возможно с той поры wiki немного обновили
и наверное никто не помешает примонтировать /usr прямо в grub если очень понадобится
система проходит обкатку и пользователи призываются к тестированию. не хочется - не надо. много людей кричало что 3 гном плох и даже сделали два!!! форка. нахуя? я извиняюсь. эти самые силы можно было потратить сделав нормальный fallback режим вместо форков.
однако 3 гном прижился и я уверен что клементин или как его там впихнут обратно если будет достаточно пользователей, но я лично обратно не хочу. видимо также будет и systemd, и grub 2.
IMHO причина здесь одна - многим не хватает текущего функционала и желание достичь новых целей. ничего плохого тут нет, просто нужно время и терпение. а кричать о недостатках надо в багзилле, тем более что на wiki они описаны и девелоперы их знают не хуже остальных - им нужен фидбек для развития.
поэтому я хочу перейти на systemd

dront78, чуть выше изложена мысль о том, что systemd плох в своей изначальной идее, в этом проблема. Это не косяки с реализацией, это архитектурные недостатки, выражающиеся в слове "не нужен") Как-то так. Мнение интересное, как ни крути.

мысль меня совершенно не поражает новизной и читать я умею.
narical, чуть выше изложена мысль, как это исправить ;)

fallback-режим?

нужно добавить в ench им в багзиллу если так хотите
мне без надобности

если сравнить с остальными мыслями - таки идиотская. нафига, объясните мне, идиоту, выносить всякие /run, /lock из /var в корень и при этом стремиться запихнуть /bin, /lib и /sbin из корня в /usr? как одно с другим сочетается? мне лично этого не понять

вопрос должен звучать не "как", а "зачем".

партия сказала "надо" - комсомол ответил "да"!
тоже примеряюсь ;)

По-моему на арчевики все докладно расписано. Когда год назад пробовал ставить, то по ней сразу и разобрался.

Я пока не смог, слишком медленно вдупляется.
Поэтому и решился задать тут вопрос - вдруг понятная хаутушка есть на русском, которая исчерпывающие ответы на все вопросы дает?

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

Любая современная система загрузки умеет устанавливать зависимости между сервисами.

что то я не нашел как это в арче сделать по дефолту. просветите

Даже не догадываюсь, как это делать в арче. Ни разу не ставил и вряд ли когда попробую.
А вот в дебиане, например, можно заглянуть в те же стартовые скрипты и посмотреть на опции Required-Start, Required-Stop, Default-Start, Should-Start, X-Start-Before и т.д.
В генте я пока не разбирался, как работает параллельная загрузка и как оно определяет зависимости, но оно работает.

в дебиане и генте я знаю как ))
в арче нету - будет systemd

и не будет. systemd не по KISS'у

Ну извините, не удержался:
пользуешься арчем - ССЗБ
:))

Эти зависимости работают только при старте системы, чтобы определить и проконтролировать порядок загрузки. В дальнейшем эти зависимости не отслеживаются, в отличие от SMF и systemd.

он же сказал современная система загрузки

да вы два троля)) друг друга плюсуете lol