aptitude предлагаетгромадноеколичестворазрешенийконфликтов,котороеменянеустраивает, apt-get remove --purge --auto-remove справляетсясзадачей.
Вместо: bash# sudo apt-get purge --auto-remove systemd я пометил пакет на удаление в интерактивном режиме aptitude и пометил sysvinit на установку. aptitude было предложено громадное количество разрешений конфликтов. У меня не хватило терпения пересмотреть все (там их за сотню), но необходимый мне вариант не был представлен. aptitude упорно предлагал оставить/обновить systemd и не ставить sysvinit. apt-get purge конешно справился с задачей, но мне интересно как завтавить aptitude в интерактивном режиме быстрее прийти с нужному мне решению? Одним из способов во многих сесиях работы с aptitude было прочтение причин почему пакет не устанавливается или кто его требует, искать и помечать на удаление/инсталяцию следующие пакеты, пока предложения aptitude по разрешению конфликтов не станут приемлимыми. Но это иногда занимало 5-10 мин клацанья. Возможно дополнительную сложность представляют зависимости из используемых веток testing/sid + i386 еще мешается.
Re: Быстреели systemd стартуетсистемучем "makefile-style concurrent boot"?
Stanislav Vlasov gmail.com> writes: > > 10 августа 2015 г., 2:20 пользователь Oleksandr Gavenko > gmail.com> написал: > > Быстрее ли systemd стартует систему чем "makefile-style concurrent boot"? > > Особой разницы на рабочей станции не увидел. В > зависимости от > поставленных сервисов может быть выигрыш в любую сторону. > Вернул на место sysvinit по инструкции http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Debian_jessie/sid_installation Без bootchart визуально ноут стартует до Iceweasel за тоже время что и при systemd (6 sec). > Вы лучше посмотрите, сколько раз в день вы загружаете > комп. У меня на > рабочей станции аптайм 39 дней и то - уборщица ходила. Закрываю крышку ноута и он уходит в suspend, обратно возвращается за 1 сек (раньше чем открылась крышка). В systemd этим занимался /etc/systemd/logind.conf опция HandleLidSwitch. После деинсталяции systemd вернул такое поведение правкой /etc/default/acpi-support, раскоментировав опцию LID_SLEEP=true. Это единственное видимое для меня различие между systemd и sysvinit.
