У тебя там что-то с демоном не так, настроил бы его, что-ли.

Некоторые демоны можно «настроить» только правкой сорцов. Раньше мне достаточно было конфиг для rsyslog написать, а чтобы использовать поттеринго-угодные тулзы, придётся демоны патчить? Всю жизнь мечтал. :D

В ядре статически собирается только самое необходимое, в initramfs запускается критичное приложение и продолжается загрузка - подгрузка модулей носителей, RAID, КФС, монтирование КФС

Да, включить контроллеры, несколько опций для RAID/LVM - это конечно очень много и нереально перегружает ядро.

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

Может сложности имеются в голове?

Нет ты.

Ты всегда такой убедительный.

Мисье не знает о том, что что-то можно (о б-чки) ВКЛЮЧИТЬ В ЯДРО НЕ МОДУЛЕМ!?!?!17171

остальных эффектов я что-то не заметил, хотя признаю, смотрел не особо внимательно

тем временем в сиде:

systemd-cgroups-agent failed to get d-bus connection

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

Это называется ?%ец.

Это нормальная поддержка или не та?

Это — нормальная.

Тут должно быть нытьё про то, что ibus не умел в ~/.XCompose когда я его в последний раз тыкал и дефолтился на (свою копию) дефолтного en-US XCompose, но я слишком давно его тыкал, чтобы уверенно сказать. По крайней мере, раньше он ломал кастомный XCompose одним фактом своего включения в отличие от uim (к которому прилагается няшный uim-fep для красноглазия без иксов).

включить контроллеры, несколько опций для RAID/LVM - это конечно очень много и нереально перегружает ядро

причем тут размер ядра, время загрузки сравни и надежность запуска критичного сервиса.

Мисье не знает о том, что что-то можно (о б-чки) ВКЛЮЧИТЬ В ЯДРО НЕ МОДУЛЕМ!?!?!17171

Месье намекает на общую бредовость вопроса о сопоставлении тёплого и зелёного.

Но так и быть, отвечу развёрнуто. Использование initramfs вместо единого-блоба-делающего-всё-что-нужно соответствует общей идее о том, что программа должна иметь возможность настраиваться при использовании, а не только при компиляции.

Наличие настроек в DE или плагинов в браузере у тебя вопросов не вызывает? Преимущества DE-с-настройками над DE-с-флагами-сборки в развёрнутых объяснениях нуждается?

Что случилось, почему с линуха на винду? Что в линухе стало кошмарным?
По моему, совсем наоборот. Линух стал юзабельнее, сообщество поболе, а win совсем кошмаром стала (да хотя она и была им, особенно во времена winXP - вообще не пойму за что её так любили). На макось бежать не хочется, с но с Дебиана больше некуда.
В мобильном сегменте, они, конечно, оба дерьмо. Что винда, бывшая годной во времена Windows Mobile, в эпоху КПК, когда в ходу были стилусы, а с приходом пальцевого ввода и ставшая WP - страх и ужас. Что линуксовая реализация в виде андроида, даже говорить не хочется, а лишь убиться об стену.

Сделай мне дифф двух презентаций

Ты, похоже, очень узко понимаешь юниксвей.

А также то, что произошёл выбор системы инициализации по умолчанию, а sysvinit всё ещё будет доступен и поддерживаться?

Ага, ща! Потом ты ставишь nginx и он ВНЕЗАПНО лопатит всю твою систему замения sysvinit на дерьмоd.

Ага, ща! Потом ты ставишь nginx и он ВНЕЗАПНО лопатит всю твою систему замения sysvinit на дерьмоd.

apt-проблемы.

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

Ну ты это, собирай не cortex-a8 и все будет хорошо.

Как ты смеешь говорить, что arm - тормозное говно?

Ага, ща! Потом ты ставишь nginx и он ВНЕЗАПНО лопатит всю твою систему замения sysvinit на дерьмоd.

Думаю, что такого не будет. Я несколько сообщений видел о том, что просто зависимость от системы инициализации сделают через виртуальные пакеты. То есть такие выкрутасы система делать не должна. Но посмотрим, что будет.

время загрузки сравни

Нахрена на сервере время загрузки???

Если это железо, там минуты проходит только POST

Если виртуалка - целых 0,0015 секунд выигрыш. Ахринеть достижение.

надежность запуска критичного сервиса

Каким макаром сервис (например апач какой-нибудь) влияет на ядро? Если это правила для какого-нибудь iptables с каким-нибудь хитрым модулем или внешний винт например - будь любезен, подгрузи, для этого вроде как придумали kmod/udev, да и руки никто не отменял

программа должна иметь возможность настраиваться при использовании, а не только при компиляции.

Каким образом это имеет отношение к initrd?

В стандартном меню третьего гнома есть поддержка японского через ibus: http://storage8.static.itmages.com/i/14/0210/h_1392048338_4606719_ea74ba6815.png

Когда я недавно пытался его использовать, то нашёл там вот это: ibus для переключения раскладок

В Гноме это отдельно исправили?

Каким образом это имеет отношение к initrd?

А ты подумай сам.

Стрелочек в гноме тоже нет, а циклическая переключалка по трём вариантам вполне работает. Но вряд ли это имеет какое-то отношение к самому ibus.

спер исходник, молодец

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

Выпил - на форум не пиши (С)

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

А потом случилось то, что алкоголики называют просветлением (С)

Каким макаром сервис (например апач какой-нибудь) влияет на ядро?

У тебя апач головного мозга - с тобой говорить не о чем. Ты спросил про преимущества initrd/initramfs я тебе написал, а то что какой-то обезьяне это не нужно мне все равно.

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

Я ~3 года использую Gentoo без initrd. Нужно разве что для какого-нибудь plymouth или hibernate - первый не использую, а для второго есть tuxonice, там инитрд не нужен.

Еще раз для тех кто в танке - я за все время использования Gentoo (~3 года) ни разу не находил его нужность. Не на одной машине, да.

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

я за все время использования Gentoo (~3 года) ни разу не находил его нужность.

Аналогично - больше 10 лет использую Linux.

Что не тянет?

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

я рад. надеюсь теперь системд доведут до ума «нормальные» разработчики.

ЗЫ Лёнька всёравно клёвый парень и молодец.

Ну выпил немного после работы, ну что, не жить мне что ли теперь?

А сокет и пайп имеют разную семантику: у одного есть понятие «слушать и принимать подключения», а у другого нет.

А почему нельзя разделить создание подключения, и наличие готового к работе сокета в который можно писать и из которого можно читать прямо как из файла?

Вторую часть сообщения ты предпочёл не заметить. Ожидаемо.

Кто ж спорит.

Правильный вариант ответа на голосовании от старого лоровского тролля https://lists.debian.org/debian-ctte/2014/02/msg00385.html

Ну ты же понимаешь, что можно либо в пайп писать, либо из пайпа читать. Для полного дуплекса нужны или так называемые bidirectional pipes (которые не везде есть), или два пайпа — в один пишем, из другого читаем.

а я еще раз предлагаю разделить линукс на десктоп и сервера

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

чет я продолбал голосования все, все без меня прошло.

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

Ничего.

но псевдоголосования я презираю: зачем их проводить если все результаты кроме «systemd» не засчитываются?

Заканчивайте распространять эту чушь. В предыдущих голосованиях побеждал вариант FD == Further Discussion == дальнейшее обсуждение. Сейчас Bdale также включил этот вариант в бюллетень, так что желающие могли проголосовать за него, однако большинство этот вариант не выбрало, поэтому победил systemd большинством голосов, чего и следовало ожидать, учитывая давно уже известную расстановку сил.

Ну так и Линус не вечен. Но незаменимых людей нет.

Правильное решение. Systemd-хейтеры будут ворчать, но прогресс не остановить.

Эпично затроллили космонавта. Пусть теперь покажет какой он не придаток дебиана

Здравый подход.

Это в твоём понимании нужно сделать, чтоб лог почитать?

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

Разговор с systemd должен быть проведён по-мужски

Итак, все мы видели, как закончились бабьи разборки по вопросу systemd. Все женщины орали своё мнение, домохозяйки ратовали за домашний openrc, кухарки столовых отстаивали интересы Canonical, поварихи элитных ресторанов совали Поттеринга во все поля с рецептов популярного systemd. В конце концов, кошачья драка закончилась и с тем, какая баба стала фаворитом подиума, стало всё ясно.

Система инициализации systemd принята как стандарт де-факто ведущими дистрибутивами, как раньше были приняты avahi и pulseaudio. Теперь необходимо провести мужской разговор с systemd. Несмотря на то, что все альтернативы systemd, рассмотренные комитетом дебиана, уж точно не подходят на роль спасительных решений, и несмотря на то, что из всего предложенного я сам лично выбрал бы при прямом голосовании systemd, достаточного решения проблем нет и не предвидится.

А именно:

- нестабильность работы перенасыщенного systemd, вылет которого означает вылет всей системы, иными словами добро пожаловать в мир KSOD'ов (черных экранов смерти)

- многочисленные проблемы безопасности, связанные со сбросом всех функций systemd в процесс инита

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

С изменением природы систем инициализации Linux входит в век давно знакомых по оффтопику проблем: нестабильность работы, завирусованность и «мышка была передвинута, перезагрузите компьютер».

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

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

Моё сообщение здесь - это начало мужского решение проблемы систем инициализации в Linux. Именно с этого сообщения начнётся разработка, которая возможно не нами и не вами будет доведена до стадии непосредственной работы с кодом - но принципы должны быть заложены отсюда: systemd свободный, а не закрытый програмный продукт, всем пора вспомнить, что свободное ПО - это не только возможность бесплатно собрать и запустить, но и возможность писать это ПО самому, даже если привыкли, что находятся Поттеринги, которые занимаются этим на работе. Всё о чём будет идти речь в сообщениях, если таковые последуют за этим, предлагаю считать касающимся systemd в том виде, каким он был на момент написания этого сообщения, упоминание последующих, как официальных, так и любых других версий systemd предлагаю упоминать отдельно.

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

И да, прочитает 2,41 анонимуса, даже до 2,5 скорее всего не дотяну.

Нет, но systemd в debian означает конец всему остальному, ради чего мы сидели на debian

Это точно, потом они также и иксы выкинут, скажут выбора нет, Fedora переходит на Wayland/Weston.

Тот же спор «микроядерная vs монолитная архитектура», только про системы инициализации.