Systemd победил в третьем голосовании по выбору системы инициализации для Debian

Если для этого нужны бинарные логи, нехай будут.

И как эти логи прочитать из другой системы, если надо будет решить какую-нибудь проблему?

юникс-вей оптимальный архитектурный принцип конструирования программ

Не не просто неоптимальный, он откровенно убогий. Из-за мизерных ресурсов команда должна была быть как можно меньше, отсюда требование «одна задача — одна команда», пайпы — что бы из этого можно было делать хоть сколь-нибудь полезные конструкции последовательным выполнением команд (тогда ведь в каждый момент времени выполняется только одна маленькая команда, а ресурсов у нас нет), текстовый формат общения — чтобы был единственный протокол для всех участников конвейера. Но время шло, мощности росли и ограничения такого подхода стали очевидны — огромный оверхед (программы стали делать свою задачу всё лучше и лучше, что далеко не всегда востребовано — сейчас никого не удивишь someprog | grep somevalue, хотя ведь запускается монстр, умеющий utf8, сложнейшие regexp'ы и прочая, а простой поиск подстроки в многомегабайтной строке я 15 лет назад реализовывал в 40 ассемблерных команд), отсутствие IPC в юниксвее (тогда никто не думал о реальной многозадачности), а текстовый формат хоть и универсален, но очень толстый и обмениваться бинарным содержимым очень даже нужно (да, современная команда cat тоже целиком и полностью неюниксвейна). Зато с ростом мощностей появились гораздо более эффективные методы, чем юниксвей — shared либы позволили разделять общий код между прогами и уже можно вместо гоняния grep'а просто вызвать какой-нибудь libpcre, демоны позволили получать результат запроса гораздо быстрее вызова программ (ведь они уже запущены и инициализированы, так что осталось выполнить только собственно запрос), хоть и занимают память постоянно, и прочая и прочая. И осталась от мёртвого юниксвея только концепция конвейера, да и то только в страшной чёрной консольке, куда даже некоторые линукс-юзеры боятся заглядывать.

Slackware.

И как эти логи прочитать из другой системы, если надо будет решить какую-нибудь проблему?

Linux-only же. Какая ещё другая система?

нужен net frameworks 3.5 sp1. думаю, делов то, накачу да побыстрому корел поставлю. не тут то было. этот нет даже с офсайта мелкомягких на их же винду не ставиться. 3 часа танцев с бубном, серфинга нета

Открой для себя Панель управления --> Программы и компоненты --> Включение или отключение компонентов Windows

Linux-only же. Какая ещё другая система?

Повторяю вопрос.
И как читать лог, если нужно будет примонтировать диск в другой линукс системе, где нет systemd?

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

Будет. Скоро её везде воткнут. Как core-utils.

И как эти логи прочитать из другой системы, если надо будет решить какую-нибудь проблему?

journalctl -D /path/to/saved/logs

Учиться вообще полезно. Хоть и не всему. ))

$ journalctl
bash: journalctl: команда не найдена

Slackware и CRUX всё ещё без Systemd. Ещё можно посмотреть на Source Mage.

в анус себе посмотри

зы капча alcohol как бы намекает что нужно пойти бухануть

Экспериментальная - это которая 9999? Если вы разработчик - то да, удобно использовать свежк, на продакшен сервер я бы не поставил экспериментал. Стейбл вполне годен, главное - собрать с нужными флагами, выпилить лишнее, меньше кода - меньше потенциальных дыр. Ну еще примочки типа хардэндед можно использовать, если очко играет.

Эм... ты неосилил поставить галочку в окошкке «turn windows features on and off?»

спасибо за иллюстрацию будничных дней алкоголика.

И какое отношение это имеет к системе инициализации?

А ты вообще читал ветку дискуссии в которую залез?

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

Анимэшнег?

В gentoo кстати есть соответствующий юз.

Кстати я об этом тоже писал. Фанатики говорят «не нужно!»

Вообще-то все 14 страниц.

В gentoo кстати есть соответствующий юз.

Он про другое.

Японская раскладка не реализуется средствами xkb вообще. В DE традиционно раскладки иксовые (следовательно, xkb).

Да, все раскладки в xorg.conf и setxkbmap, а также все костыли в xmodmap — тоже не в ту сторону.

Кстати, пример софта, не умеющего японский ввод — dmenu.

На самом деле некоторые — как тот кот, которому делать нехрен.

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

Когда CTO Боинга или Эксон-Мобил говорит что они тратят слишком много времени на допиливание, это не звучит как мяуканье :)

Sysvinit — превосходная система инициализации, а systemd — жуткое тормозное тупое говнище. К тому же для работы с systemd парой рукописных скриптов не обойдешься!

в том и проблема - рукописные скрипты, которых быть не должно. И гигабайты текстовых логов, которые невозможно читать в режиме DEBUG, а писать код который загрузит все это в какой нибудь BIE времени нет. И куча рейсов между скриптами и модулями во время загрузки, и допиливание сервера после загрузки в rc.local, который в идеале должен быть чист, так как после загрузки, на хорошо настроенном сервере делать уже ничего не надо.

Когда админишь локлахост или маленькую кучку хостов, где все знаешь, (и никому ничего не расскажешь), можно конечно накручивать свои конфиги до посинения. Но когда серверов тысячи, они используют нетривиальное железо и разворачиваются и переустанавливаются на полном автомате, sysv не тянет.

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

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

Когда админишь локлахост или маленькую кучку хостов, где все знаешь, (и никому ничего не расскажешь), можно конечно накручивать свои конфиги до посинения. Но когда серверов тысячи, они используют нетривиальное железо и разворачиваются и переустанавливаются на полном автомате, sysv не тянет.

О, эту блевоту я уже наслушался. Такая система есть. И она уже развернута с активдиректори, ексчендж, мсскуль, линк, сццм, ском, хипер-в и прочим. Оно уже работает. Нахер вторая винда?

О, эту блевоту я уже наслушался. Такая система есть. И она уже развернута с активдиректори, ексчендж, мсскуль, линк, сццм, ском, хипер-в и прочим. Оно уже работает. Нахер вторая винда?

тебе не нужно, оставайся на винде

так оно с дебиана и в бубунту переползет не?

sed — не юниксвей, grep — не юниксвей

тогда никто не думал о реальной многозадачности

Кто ты и что сделал с redgremlin-ом?

прочитай данные из сокета в линуксе в духе юникс-вея

man netcat

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

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

Так нахрена гнать через скрипты охрениад ненужных строк, когда можно попросить journalctl выдать тебе сразу всю нужную информацию без всей ненужной?

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

Это может потребоваться только больному на всю голову. Логи для того и существуют, чтобы их писать, а не игнорировать.

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

В частности, бывают данные, которые остаются актуальными для анализа годами, а бывают — которые уже через сутки не нужны ни в каком виде. Или через 10 минут. Засирать ими долгоживущий лог, чтобы потом при чтении фильтровать каждый раз - это, конечно, может потребоваться только НЕ больному на всю голову.

Но когда серверов тысячи, они используют нетривиальное железо и разворачиваются и переустанавливаются на полном автомате, sysv не тянет

Что не тянет?

если systemd позиционируется как система, в основном направленная на ускорение процесса загрузки, то на десктопе или ноуте это не плохо, но на сервере ведь перезагрузка происходит в худшем случае раз в месяц, что решают 30 - 40 секунд, выигранные при перезагрузки, остальных плюсов systemd не знаю и не хочу знать.

А что не так? Нынешний sed — Тьюринг-полный язык программирования, на котором даже игры есть, а не stream editor, нормальное IPC появилось только в UNIX System V, а до того многозадачность фактически заключалась в эмуляции одним компьютером N-ного количества однозадачных терминалов.

[многобуков поскипано]

Извини но ты упорот.

Возьмём такие утверждения.

Есть rsyslog, который решает ровно одну задачу и делает это прекрасно. Есть dbus, который решает ровно одну задачу и делает это хорошо. Есть даже PA от того самого Поттеринга, который тоже предназначен для решения одной и только одной задачи. Он хоть и глучит у некоторых, но тоже хорошая программа. Такой список можно долго продолжать.

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

Это реальные факты.

А твоё бла-бла-бла про пайпы - словоблудие сплошное.

Я понимаю, что емаксеры от такого комбайна должны быть в восторге. У них тоже текстовый редактор умеет всё, и всё умеет плохо. Но я не емаксер, к счастью.

То есть для каждого канала передачи данных будем писать свой cat?

Ну вот прошу его вывести сообщения от нужного демона, а их там охрениллиард

У тебя там что-то с демоном не так, настроил бы его, что-ли. В любом случае journalctl --no-pager SYSLOG_IDENTIFIER=mydaemon | super_parser.pl спасёт отца русской демократии. И при охрениллиарде записей будет гораздо быстрее grep mydaemon /var/log/verylong.log | super-parser.pl

Не знал. Теперь буду иметь ввиду.

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

Зачем мне холодильник, если я не курю?

судя по тому, сколько дебианщиков уже завели трактор, многие сидели на debian'e только ради sysvinit.

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

если systemd позиционируется как система, в основном направленная на ускорение процесса загрузки

Она никем так не позиционируется. Ускорение загрузки — приятный побочный эффект, не более.

одну инит систему не оставят, намертво не прикрутят

ОСтавят и прикрутят. Перестанут запускаться иксы, гном и где. nginx будет требовать специального модуля для запуска.

Неужто на макось придётся переходить :((

пшпш аудио

смешно

ты упорот.
Есть rsyslog, который решает ровно одну задачу

Нет ты.

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

Жуть-беда. Какой системой инициализации должен комплектоваться Debian Stable по умолчанию? (комментарий)

То есть для каждого канала передачи данных будем писать свой cat?

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

(Капча connection anobala как бы намекает)

sed — не юниксвей, grep — не юниксвей
тогда никто не думал о реальной многозадачности

А что не так?

Всё процитированное - либо вранье, либо заблуждения.

Нынешний sed — Тьюринг-полный язык программирования

Нерелевантно.

нормальное IPC появилось только в UNIX System V

В зависимости от смысла, вкладываемого в термин «нормальный», нормальным IPC были pipe в 6 Edition, или FIFO в System III, или сокеты в BSD 4.x (с натяжкой), или STREAMS в System V Release 2.

А вот Indian Hill IPC всегда было говном (и никогда не считался Unix-way, кстати - его спроектировала и реализовала левая группа в AT&T, не имевшая раньше никакого отношения к Unix).

а до того многозадачность фактически заключалась в эмуляции одним компьютером N-ного количества однозадачных терминалов

Это бред - говорю тебе и как историк-любитель, и как системный программист.