initscripts-fork 2012.12.1

в init-системе архитектурно не была предусмотрена поддержка зависимостей

…ибо это не её задача.

</thread>

Не нужно, systemd загружается куда быстрее всех этих скриптовых инитов.

systemd загружается куда быстрее всех этих скриптовых инитов

Так и запишем: systemd нужен для нищебродов, не накопивших на нормальный SSD. :)

когда SSD станут по объему 2тб за человеческую сумму тогда и возвращайся

Тоже мне, нашел плюс. Конечно, быстрее загружается: у тебя пол-системы отваливается на хрен!

у ничего не отвалилось все работает нормально

В мастдайке тоже ничего не отваливается и вирье не заводится, если ее только по назначению использовать (все-таки, игровая прошивка). А если поработать захочешь...

с наркобаронами скооперироваться не хочешь?

http://lsd-linux.forums.gs/

Синофски-шмановски (комментарий)

А как быть со 100500 пакетами, для которых удалят rc-скрипты и оставят только systemd-юниты?

И из официальной репы, и в AUR. Я уже видел несколько комментов в AUR в стиле «в следующей версии я добавлю поддержку systemd и грохну поддержку initscripts».

Придется еще поддерживать аццкое количество пакетов packagename-sysvinit, в которых будут жить соответствующие rc-скрипты. И писать обертку к pacman'у, которая будет их автоматом вытягивать для соответствующих пакетов. Костыль на костыле.

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

Пора уже форкать этот ваш арч :)

А как быть со 100500 пакетами, для которых удалят rc-скрипты и оставят только systemd-юниты? … Придется еще поддерживать аццкое количество пакетов packagename-sysvinit, в которых будут жить соответствующие rc-скрипты. И писать обертку к pacman'у, которая будет их автоматом вытягивать для соответствующих пакетов.

Зачем так всё усложнять? Все выкинутые скрипты будут перенесены в initscripts-fork и ставиться вместе с ним. Конечно, это не идеальное решение, но всё же в разы лучшее, чем вагон «packagename-sysvinit».

KISS

Мне кажется, пора форкать арч

Нафига нам ЕЩЁ ОДИН дистр, который будет только отвлекать силы и дублировать уже сделанную работу, когда можно просто обойтись насколькими пакетами в AUR?

Все выкинутые скрипты будут перенесены в initscripts-fork и ставиться вместе с ним.

Во-первых, все-все никогда не перенести, потому что покрыть всю махину репозитория+aur в одном пакете равносильно делению на ноль.

Во-вторых, зачем мне в rc.d куча ненужных мне init-скриптов? Я хочу иметь там только скрипты для тех пакетов, которые на самом деле у меня стоят, а не для всего репозитория и какого-то куска AUR.

Нафига нам ЕЩЁ ОДИН дистр, который будет только отвлекать силы и дублировать уже сделанную работу, когда можно просто обойтись насколькими пакетами в AUR?

См. ответ на первый пункт. :)

Держать альтернативную init-систему в aur - это значит, постоянно мэйнтейнить все нужные init-сценарии для каждого из пакетов. В итоге все скатится в свалку (хотя там и так свалка в aur, из пакетов вида пакет-с-фичей-а, пакет-с-фичей-б, пакет-с-фичами-а-б-но-без-в, так что все равно туда укатится).

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

cast val-amart

все-все никогда не перенести, потому что покрыть всю махину репозитория+aur

Разумеется, в первую очередь я буду мейнтейнить то, чем пользуюсь сам. Если кто-то возмётся за остальное, то я возражать не буду. :)

Во-вторых, зачем мне в rc.d куча ненужных мне init-скриптов?

У меня была идея вкорячить в PKGBUILD или Makefile код, который бы анализировал имеющиеся в системе пакеты и устанавливал только нужные скрипты. Но тогда юзеру пришлось бы часто переустанавливать его.

cast val-amart

Неправильно. Надо так:

cast val-amart

Разумеется, в первую очередь я буду мейнтейнить то, чем пользуюсь сам. Если кто-то возмётся за остальное, то я возражать не буду. :)

Так думали и мэйнтейнеры арча, переходя на systemd. Раз initscripts никто не хочет на себя взять - ну и кому он нужен. :)

Не пробовал вписаться в ряды мэйнтейнеров и возжелать поддерживать sysvinit, кстати? Имхо, это было бы проще.

У меня была идея вкорячить в PKGBUILD или Makefile код, который бы анализировал имеющиеся в системе пакеты и устанавливал только нужные скрипты. Но тогда юзеру пришлось бы часто переустанавливать его.

В общем, все равно костыль. :)

Да кстати, стань мэйтенером, и глядишь вернут в офф репы

Не пробовал вписаться в ряды мэйнтейнеров и возжелать поддерживать sysvinit, кстати? Имхо, это было бы проще.

Я бы с радостью, но, судя по треду val-amart'а, уже поздно.

«в следующей версии я добавлю поддержку systemd и грохну поддержку initscripts».

Один фиг init-скрипты писать, или, хотябы, дописывать самому приходится, когда пакетишь.

Да кстати, стань мэйтенером, и глядишь вернут в офф репы

Увы, у меня кроме дома и работы есть еще дела-заботы. Да и вообще я свой дистрибутив хотел пилить на досуге, арч не идеален, сломался - значит, это повод сделать что-нибудь лучше.

Та я не тебе писал, ошибся, пардон.

Я бы с радостью, но, судя по треду val-amart'а, уже поздно.

А, понятно. Хотя, мне кажется, и бесполезно. Потом еще прикрутят какую-нибудь новую сверкающую бесполезную штуку, и опять поддерживать в aur нормальную прежнюю работающую подсистему.

Один фиг init-скрипты писать, или, хотябы, дописывать самому приходится, когда пакетишь.

Ну это понятно, ибо не совсем стандартная система инициализации. Но она архипростая и прозрачная, в отличие от того, что выбрали сейчас.

Главное, чтобы его можно было легко поставить вместо systemd.

У меня 5 машин, которые я врядли буду переводить на systemd в ближайшем будущем, так что готов поддержать. По крайней мере я не буду выкидывать rc.d из своих пакетов до последнего.

А если всё пойдет хорошо, м быть смогу запихнуть это в [community].

Свисти, если получится.

Ну это понятно, ибо не совсем стандартная система инициализации. Но
она архипростая и прозрачная, в отличие от того, что выбрали сейчас.

Так я к тому, что выкидывание init-скрипта разработчиком не проблема для мантейнера в дистрибутиве.

Долго думал о нужности мероприятия.

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

сколько в треде анально-зондированных...

Да ты со своим openrc вообще молчал бы :)

У меня была идея вкорячить в PKGBUILD или Makefile код, который бы анализировал имеющиеся в системе пакеты и устанавливал только нужные скрипты. Но тогда юзеру пришлось бы часто переустанавливать его.

Кстати, есть вариант проще. И можно даже помочь в допиливании. Если включат в следующий пакман - можно не бояться засилия systemd, и держать в AUR кучу пакетов с sysvinit-скриптами, которые будут по триггеру ставиться автоматически юзерам: https://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks

Достаточно будет, чтобы юзеры поставили из AUR пакет со скриптом, который по имени пакета ресолвит sysvinit-скрипт-пакет, и автоматом ставит/апгрейдит его из AUR. Ясно, что в этот пакет будет положен и триггер.

Хотя тоже костыль, все же официальный. :)

Кстати, есть вариант проще. И можно даже помочь в допиливании. Если включат в следующий пакман - можно не бояться засилия systemd, и держать в AUR кучу пакетов с sysvinit-скриптами, которые будут по триггеру ставиться автоматически юзерам: https://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks

Хорошая идея, но мне не хотелось бы засорять AUR кучей мелких однотипных пакетов.

Можно сделать проще: все доступные скрипты хранятся в /usr/share/ (надеюсь, юзеры не сильно будут жалеть о лишних 1-2 Мб на диске), при установке/удалении пакета триггер проверяет изменения и копирует/удаляет необходимые скрипты в /etc/rc.d/. Что скажешь?

Ты лучше клич пусти среди программистов-арчеров, вдруг наберешь команду по «клонированию» арча. И появится приличный дистрибутив, в котором слово «поттеринг» является матом.

Ты лучше клич пусти среди программистов-арчеров, вдруг наберешь команду по «клонированию» арча.

Тогда лучше сразу объединяться с archbang (там поццеринга тоже не любят) или lsd linux. Но я пока планирую остаться на арче.

P.S. А что у тебя со звёздами? :)

лучше сразу объединяться с archbang (там поццеринга тоже не любят)

Спасибо за наводку, сейчас почитаю.

// почитал. Фигня какая-то: репы-то у них арчевские, т.е. все равно Поц и там своим поцем наведет шухера.

А что у тебя со звёздами?

Не сдержался...

Можно сделать проще: все доступные скрипты хранятся в /usr/share/ (надеюсь, юзеры не сильно будут жалеть о лишних 1-2 Мб на диске), при установке/удалении пакета триггер проверяет изменения и копирует/удаляет необходимые скрипты в /etc/rc.d/. Что скажешь?

Да, идея хорошая. Интересно, к какой версии они дозреют до триггеров. Хотя можно и помочь с этим, конечно.

накатай пжл инструкцию как вернуться с systemd на initscripts-fork.

накатай пжл инструкцию как вернуться с systemd на initscripts-fork.

1. Поставить initscripts-fork.
2. Удалить из параметров ядра init=/sbin/systemd.
3. Рекомендуется: перевести все настройки в rc.conf, т.е. локаль и настройки шрифтов — в LOCALE/CONSOLEFONT/CONSOLEMAP, загружаемые модули — из /etc/modprobe.d/ и /etc/modules-load.d/ (автоматически сгенерированные файлы трогать не надо) в MODULES, запускаемые демоны — в DAEMONS и т.д. Подробности смотри в комментах и man rc.conf.

Утилитами типа localectl пользоваться не нужно. Кроме того, initscripts-fork 2012.12.1 (комментарий).

networkmanager не стартует. ругается на ненайденные команды msg_busy и msg_ok

msg_busy и msg_ok

Инитскрипты от LSD ставил, да? (они при установке модифицируют все скрипты в /etc/rc.d). Переустанови networkmanager.

каюсь. грешен. баловался lsd.

переустановил networkmanager. он запустился, но не увидел сетевые интерфейсы.

решил дальше не испытывать судьбу на рабочей тачке и вернулся обратно на systemd :)

А зачем тебе NM? Скриптик на баше тебе написать, чтобы менять настройки сети, если ты так часто разные шнурки в компьютер втыкаешь?

мне NM за тем, что я один раз им сеть настроил и больше как-то не лез в это дело. тем более, что инэт бежит по кабелю к единственному компу. пользуюсь лишь плазмоидом от него, чтоб сетевую активность посмотреть.

а тут сетка автоматом не поднялась и на автопилоте откатился на предыдущую рабочую версию)))

мне NM за тем, что я один раз им сеть настроил

Ах, его ещё НАСТРАИВАТЬ нужно? Нафиг он тогда нужен? :)

Кстати, какое у тебя подключение?

пользуюсь лишь плазмоидом от него, чтоб сетевую активность посмотреть

Между прочим, в кедах есть плазмоид «Стетевой монитор», к-рый делает всё тоже самое, только без привязки к NM.

mamma mia…

Что там настраивать-то? На один раз — ifconfig + route, на несколько — в /etc/rc.conf (если одна сетевушка) или в /etc/network.d + /etc/udev/rules.d — если несколько. Вот, блин, любишь проблемы выдумывать...

А с NM я даже не представляю, как сеть настраивать. Да и на кой черт он нужен?

Нафиг он тогда нужен? :)

Что-бы делать, например, вот так:

(if (string= (shell-command-to-string "nmcli -t -f name con status") "Work\n")
    (setq user-mail-address "fio@work.com")
  (setq user-mail-address  "trololo@gmail.com"))

Кстати, какое у тебя подключение?

pppoe, которое по идее должно быть настроено через pppoe-setup. и даже работать должно, потому как как-то же я на арч кеды с НМ поставил. но там пинга не было. я и откатился не раздумывая. вроде раньше лечил такое убиванием dhcpd...

есть плазмоид «Стетевой монитор»

он у меня тож есть. и НМ есть. активность в основном сетевым монитором и отслеживаю, а в НМ лезу что бы посмотреть количество входящего/исходящего трафика, ну и еще сетевую активность на красивом графике посмотреть)) не спрашивай почему я так делаю. сам не знаю)))

shell-command-to-string

Это мастдайка что ли?

if ifconfig eth3 2>/dev/null; then
    IP=$(ifconfig eth3|grep "inet "|awk '{print $2}')
    [ $IP = $home_IP ] && echo "home" || echo "work"
else
    echo "no network!"
fi

Да и на кой черт он нужен?

не знаю. но на какой-то же я его поставил когда-то%)

На один раз — ifconfig + route, на несколько — в /etc/rc.conf (если одна сетевушка) или в /etc/network.d + /etc/udev/rules.d — если несколько

я вообще делал pppoe-setup и все!))) но там вроде были какие-то запары с получением dns серваков от прова что ли... возможно поэтому НМ и накатил, находясь под ностальгией от времен проведенных на кубунту с чакрой.

кстати, должен признать он уже научился поднимать сетку! так что не такая уж бесполезная штука

[ $IP = $home_IP ] && echo "home"

Ну да, в век хоумроутеров и 192.168.0.1/24 - актуальный совет :D