LINUX.ORG.RU

systemd 218

 ,


3

5

12 декабря был представлен очередной релиз системного менеджера systemd, совмещающего в себе функции системы инициализации, ведения журнала и управления сессиями пользователей. systemd основан на модели зависимостей (в противовес событийной модели), производит отслеживание процессов запущенных сервисов при помощи механизма cgroups ядра Linux, поддерживает механизмы сокет- и dbus-активации сервисов и предоставляет удобный декларативный синтаксис для описания демонов и других сущностей. Это позволяет производить агрессивную параллелизацию при запуске и остановке сервисов.

В рамках проекта также разрабатывается ряд легковесных приложений и демонов, выполняющих второстепенные, но распространённые задачи по управлению системой — от настройки подсистемы VT (systemd-vconsole-setup) до управления сетью (systemd-networkd) и профилирования загрузки (systemd-bootchart).

Список изменений:

  • Все компоненты systemd, обладающие конфигурационными файлами в /etc/systemd, теперь умеют считывать настройки из соответствующих *.d-директорий в /usr/lib, /run и /etc.

    Например, /etc/systemd/system.conf можно дополнять из /{usr/lib,run,etc}/systemd/system.conf.d/*.conf.

  • Добавлена команда systemctl edit, которая позволяет редактировать unit-файлы (используется редактор, указанный в переменной окружения $EDITOR).

    Возможные режимы работы таковы:

    • (по умолчанию): «режим дополнения», т. е. редактирование нового drop-in'а (создаётся и открывается /etc/systemd/system/$unit.d/override.conf)
    • --full: «режим исправления», т. е. редактирование всего юнит-файла (он предварительно копируется в /etc/systemd/system, если необходимо)
    • --runtime: «режим временных изменений», т. е. вместо /etc используется /run и все внесённые изменения живут только до перезагрузки
  • Команда systemctl is-enabled теперь выводит «indirect» вместо «static» (при этом код возврата равен 0) в тех случаях, когда секция [Install] юнита содержит только директивы Also=, т. е. когда сам юнит не может быть включен, но «включает» другие юниты.
  • Команда systemctl status ЮНИТ теперь выводит также и «предлагаемое» состояние юнита согласно preset'ам. Это показывает, должен ли юнит быть включен согласно дистроспецифичному дефолту.

    Пример:

    $ grep -R remote-fs.target /usr/lib/systemd/system-preset
    /usr/lib/systemd/system-preset/90-systemd.preset:enable remote-fs.target
    
    $ systemctl status remote-fs.target
    ● remote-fs.target - Remote File Systems
       Loaded: loaded (/usr/lib/systemd/system/remote-fs.target; disabled; vendor preset: enabled)
    

  • Команда systemd-run теперь поддерживает отложенный запуск команд в стиле at(1) (параметры командной строки --on-calendar и аналогичные). Это реализовано с помощью создания временного timer-юнита наряду с основным service-юнитом (поддержка создания timer-юнитов как раз была добавлена в API systemd).
  • В команде busctl, предназначенной для работы с шиной D-Bus, добавлены следующие подкоманды и параметры командной строки:
    • busctl capture (захват всех данных, проходящих через шину, в формате libpcap)
    • busctl tree (отображение дерева объектов для конкретного сервиса или для всех сервисов на шине)
    • busctl introspect (отображение подробной информации о конкретном объекте на шине)
    • busctl call, busctl get-property и busctl set-property (предназначение очевидно из названий)
    • busctl --augment-creds= (включение или отключение сбора вспомогательных данных о процессах на шине из /proc)

      Последняя опция по умолчанию включена, но в некоторых случаях это может привести к race conditions, поэтому и была добавлена возможность её отключения.

  • В команде journalctl добавлены параметры командной строки --vacuum-size= и --vacuum-time=, позволяющие принудительно удалить старые файлы журнала. Как легко понять из названий параметров, критерием очистки может быть или суммарный размер файлов журнала, или давность сообщений в конкретном файле.
  • В команде systemd-nspawn добавлены параметры командной строки --link-journal=try-guest и --link-journal=try-host, которые работают аналогично значениям guest и host (а именно — включают объединение журналов хоста и контейнера), но не возвращают ошибку, если на хосте ведение постоянного журнала отключено.

    Параметр командной строки -j теперь является синонимом для --link-journal=try-guest.

  • Команда systemd-inhibit при отображении списка активных ингибиторов теперь поддерживает фильтрацию по типу (block или delay).
  • Для каждой директивы вида ConditionXYZ= в секции [Unit] unit-файлов добавлена аналогичная директива AssertXYZ= в той же секции.

    Отличие между ними состоит в том, что невыполнение Condition-директив приводит к пропуску (игнорированию) юнита, а невыполнение Assert-директив переводит юнит в состояние «failed».

  • В секциях [Scope] и [Service] unit-файлов добавлена директива Delegate=, разрешающая процессам юнита самостоятельно управлять своим поддеревом контрольных групп.
  • В секции [Service] unit-файлов добавлена директива SmackProcessLabel=, позволяющая установить для всех процессов юнита указанную метку SMACK64.
  • Директива ConditionSecurity= unit-файлов теперь может принимать значение audit, что будет приводить к проверке доступности audit-подсистемы ядра.
  • systemd-coredump теперь собирает и кладёт в журнал вместе с core-дампом некоторое количество метаданных об упавшем процессе, а именно:
    • контрольные группы, к которым принадлежал процесс (/proc/$PID/cgroup)
    • список переменных окружения и их значения (/proc/$PID/environ)
    • карту адресного пространства процесса (/proc/$PID/maps)
    • рабочую директорию (/proc/$PID/cwd)
    • корневую директорию (/proc/$PID/root)
    • состояние процесса (/proc/$PID/status)
    • список открытых файловых дескрипторов (/proc/$PID/fd)
  • journald теперь умеет собирать сообщения audit-подсистемы ядра (с обработкой сопутствующих метаданных) и записывать их в общий лог. В частности, это означает, что journalctl становится альтернативой традиционному audit-клиенту ausearch.
  • systemd-networkd теперь поддерживает:
    • конфигурирование VXLAN-устройств (секция [VXLAN] netdev-файлов)
    • указание «стоимости» портов bridge-устройств (директива Cost= в секции [Bridge] network-файлов)
    • настройку правил IP source routing (директива Source= в секции [Route] network-файлов)
    • выбор сетевого интерфейса по его исходному имени (до переименования; директива OriginalName= в секции [Match] link-файлов)
    • изменение MAC-адреса и MTU интерфейса из network-файлов (директивы MACAddress= и MTUBytes= в секции [Link] network-файлов)
  • В systemd-networkd начата работа по реализации протокола PPPoE.
  • NSS-модуль nss-myhostname теперь ресолвит имя «gateway» в IP-адрес шлюза по умолчанию. Если таковых несколько — они сортируются по значению метрики.

    Отмечу, что это изменение не нарушает работу конфигураций, в которых имя «gateway» уже как-либо используется, поскольку модуль nss-myhostname обычно идёт последним в списке NSS-модулей.

  • macvlan-устройства, создаваемые systemd-nspawn внутри контейнеров, теперь имеют стабильные MAC-адреса (в том смысле, что они не будут изменяться каждый раз).
  • systemd-cryptsetup-generator теперь поддерживает указание key-файлов и назначение имён для отдельных устройств из командной строки ядра (luks.key=<UUID>=<имя файла> и luks.name=<UUID>=<назначаемое имя устройства>).
  • В systemd-tmpfiles добавлено действие t — назначение файлу произвольных расширенных атрибутов (xattrs).
  • systemd-localed теперь опционально зависит от libxkbcommon. Эта библиотека будет использоваться для проверки корректности устанавливаемых настроек раскладки клавиатуры X11 (напр., с помощью localectl set-x11-keymap).
  • В systemd-hostnamed список текстовых описаний типов системы (chassis type) был пополнен значением «embedded».
  • systemd-rfkill теперь ассоциирует запоминаемое состояние rfkill'а не с его именем (rfkill0, rfkill1, ...), а с комбинацией его типа (wlan, bluetooth, ...) и свойства ID_PATH.

    Это связано с тем, что имя rfkill'а не обязано сохраняться между перезагрузками или переподключениями устройства. Более того, в последнем случае оно никогда не остаётся прежним.

  • База данных аппаратного обеспечения (hwdb) udev'а теперь содержит базу данных разрешений оптических сенсоров мышей. Она будет использоваться в libinput для автоматической коррекции ускорения курсора.

    Ситуация более подробно описана в этом сообщении.

  • systemd теперь умеет корректно обрабатывать ситуации, в которых система одновременно
    • не имеет файла /etc/machine-id
    • запускается с корневой ФС в режиме «только чтение»

    Для обработки этих случаев была добавлена вспомогательная утилита systemd-machine-id-commit, которая запускается сразу после перемонтирования корневой ФС в режим «чтение и запись» и атомарно перемещает временный файл machine-id из tmpfs в /etc/machine-id.

>>> Объявление о релизе

★★★★★

Проверено: maxcom ()
Последнее исправление: maxcom (всего исправлений: 7)
Ответ на: комментарий от Deleted

Очень хороший код очень легко читать

Check.

intelfx ★★★★★
() автор топика

Интересные "аргументы" тут встречаются. systemd плохой потому, что pulseaudio пыщ-пыщ.

kernelpanic ★★★★★
()
Ответ на: комментарий от Deleted

не, не глючит. когда удаляешь пульсаудио, глюк уходит вместе с ней.

Вообще-то алса и правда глючит. В частности на некоторых материнках ASUS у меня не работает встроенный звук. Точнее - захват звука. Вывод нормальный. И это без пульсы. С пульсой - так-же, разумеется.
Jack - однопользовательский. По ряду причин - мне это не подходит.
Попробовать, чтоль OSS?

kir2yar
()
Ответ на: комментарий от Deleted

Отучайся говорить за всех. Тот же Патрик, например, отказался.

При всем моем уважении к слаке, слака - явно не самый распространенный вариант линукса. Думаю, даже у какой-нить болген-ос больше пользователей. Потому не показатель.
В вот редхет+дебиан(включая убунту) - уже чуть-ли не 90% линуксов.

kir2yar
()
Ответ на: комментарий от Deleted

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

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

anonymous
()
Ответ на: комментарий от kir2yar

алса не идеальна, и ежу понятно :) мы тут про то, что без пульсаудио лучше чем с.

слака - явно не самый распространенный вариант линукса

Думаю у слаквари больше пользователей чем принято думать. Дистр возраста дебиана и имеет массу поклонников. Работает и всё, просто меньше упоминаний и рекламы. А ввиду того что сам дистрибутив - это ванильный софт и минимум «дистрибутивности» - то и по багам упоминаний маловато. Всё направляется в багтрекеры програм и майллисты. К тому же молодняк, от которого много рекламы, споров, скриншотов и апологетики - не очень жалуют слакварю :)

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

мы тут про то, что без пульсаудио лучше чем с.

На одной звуковухе - да, пульса излишество. Но у меня их целая россыпь. И не редко приходится переносить звук работающего приложения с одной, на другую.
Пульса таки имеет смысл. Поскольку я пока не видел других инструментов, которыми можно перенести звук с hdmi на синезуб не разрывая канал. Особенно это нужно при использовании ip-телефонии.

Думаю у слаквари больше пользователей чем принято думать.

Вполне возможно. Но если слака это «ванильный софт и минимум «дистрибутивности»», то маловероятно, что она будет править бал.

просто меньше упоминаний и рекламы.

И это плохо. Дело в том, что опенсорс питается душами. Чем больше пользователей у проекта, тем активней он развивается и живет.
Когда каноникл перетянули на себя часть пользовательской базы дебиана - дебиану стало сложновато поддерживать все свои архитектуры.
То-же будет и со слакой. Если разработчики кед и гнома решат что им жизненно нужен logind - то в слаке либо не будет кед/гнома, либо будет logind.
Поскольку у слаквари нет достаточно рабочей силы, что бы самостоятельно поддерживать ветку кед/гнома без systemd.

В этом плане у не любителей systemd есть только один выход - активно развивать дистрибутив в котором нет системд.
К примеру, тот-же девиан.

На практике, большая часть людей, которые умеют и, главное, могут писать код - относится к системд нейтрально. Он им не мешает, а местами помогает. А вот те, кому системд не нравится - до сих пор не могут собраться в одну группу. Вместо этого - много и громко орут по форумам.
Пример? Меня системд устраивает. Он решает мои задачи. И дает мне нужные мне инструменты. У меня нет необходимости что-то менять, потому я могу развлекаться умеренным троллингом. А вот тем, кому системд не нравится - как раз нужно начать работу. И не орать по форумам, а сесть за редактор и начать писать код. Собраться вокруг ОДНОГО дистрибутива (на кучу, скорее всего, деятельного народу не хватит) и вдохнуть в него жизнь.

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

kir2yar
()
Ответ на: комментарий от kir2yar

перенести звук с hdmi на синезуб не разрывая канал. Особенно это нужно при использовании ip-телефонии.

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

По поводу остального - многие орут на форумах не потому что хотят забрать у любителей системде свободу стоя в гамаке. Они всего лишь хотят чтоб оставили возможность выбора. Например первым хочется менеджер устройств в системде, ради бога. Но нет - слили в одну кодовую базу. А когда прислали патч - послали в лес. Также и с остальными поглощенными проектами. Говорят поклонники поттеринга, да и сам поттеринг про свободу и сотрудничество, а стоит призвать к свободе и сотрудничеству - так посылают и таких как Ян в лес. Говорят про свободу и форки, а стоит появиться форку, как обольют говном с ведра и гентушников с удавом, и uselessd, и заимствования фич в upstart и т.д.

Deleted
()
Ответ на: комментарий от Deleted

Они всего лишь хотят чтоб оставили возможность выбора.

У них она есть. Благо gcc может скачать каждый.
И это единственная свобода, которая есть. Единственная возможность выбора. Все остальное - подачки от посторонних людей, которым ты ни цента не заплатил.

А когда прислали патч - послали в лес.

Да, у авторов systemd есть такая свобода. И это тоже правильно.

Говорят про свободу и форки, а стоит появиться форку, как обольют говном с ведра и гентушников с удавом, и uselessd, и заимствования фич в upstart и т.д.

А вот тут - типичное человеческое поведение. Хейтеры появились сильно раньше чем та-же история с удавом. Тут обе стороны швыряют примерно равное количество говна. Так-что не вижу смысла мерить говнопоток.
Черт. Да единственное, что можно померить - код и результативность.
Потому, тот факт, что на системд перешли основные дистрибутивы фактически является победой ситемд. У системд резко увеличилось количество тестеров. Немного возросло количество программистов. В дальнейшем новый софт будет завязываться на апи системд.
Иначе говоря, потопить системд можно только резко увеличив количество людей, которые будут готовы проводить работы по «отвязыванию» от системд.
А самое забавное - если бы системд был хотя-бы на четверть так ужасен, как тут стенают - он бы просто умер как апстарт. Или был уделом маргиналов, как openrc.
Вообще, мне нравится опенсорс. Тут все перемены к лучшему. Так или иначе. Рано или поздно.

kir2yar
()
Ответ на: комментарий от kir2yar

В этом плане у не любителей systemd есть только один выход -
активно развивать дистрибутив в котором нет системд.

Бред. Вполне можно заниматься выпиливанием системд и оттуда, где он есть. Что и делает убунта.

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

Вы соц опрос проводили? У дебиановцев спросите.

Пример? Меня системд устраивает.

Перл... Вы дистростроитель чтоль? Можно узнать, в какой дистрибутив контрибьютите, и каков ваш вклад туда? А если вы не дистростроитель - кого волнует, что вас устраивает?

И не орать по форумам, а сесть за редактор и начать писать
код. Собраться вокруг ОДНОГО дистрибутива (на кучу, скорее
всего, деятельного народу не хватит) и вдохнуть в него жизнь.

Вам уже сто раз было сказано, что убунта этим и занимается. Наняли разработчиков специально для этого, сделали systemd-shim, адаптировали cgmanager, собираются логид пилить... Вы, видимо, только самого себя слышите?

Опенсорс - истинное проявление свободы.

Поучите дебиановцев и гентушников свободе, которые с этим системд уже задолбались. Пока они там голосования проводят, вы бы им про свободу вбрасывали, а то сами по форумам только и мастер орать. :)

anonymous
()
Ответ на: комментарий от anonymous

Про Debian неправда. Голоса «за» аргументировались
техническими преимуществами.

Знаете ли, трудно поверить в такое, при выполнении следующих двух условий:

1. Системд с апстартом для дебиана практически на равных по фичам, это многие голосовавшие заявляли.

2. Против системд (вплоть до ухода из проекта) была чуть ли ни половина.

Если я не прав - предоставьте пруф, что та, оставшаяся половина, вся была единодушно за, а не просто с безысходностью смирилась. У них там, в обсуждении голосования, раз сто было сказано, что наличие полноценной и совместимой замены бы многое изменило, но её надо делать, и пока её нет, голосуем так.

Например, тут: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#5977

anonymous
()
Ответ на: комментарий от anonymous

Системд с апстартом для дебиана практически на равных по фичам, это многие голосовавшие заявляли.

Практически, да не совсем. Скажем, часто упоминалось отсутствие полноценной поддержки socket activation, несовершенная архитектура, основанная на событиях, а не зависимостях, отсутствие поддержки cgroups для надёжного разделения сервисов, менее проработанные пользовательские утилиты...

Против системд (вплоть до ухода из проекта) была чуть ли ни половина.

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

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

Для членов Технического комитета были подготовлены целые виртуальные машины с разными системами инициализации, чтобы они могли подробно их исследовать и сделать обоснованный выбор. Поэтому вам просто нужно почитать сообщения проголосовавших за systemd. Пример: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#1729.

Например, тут:https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#5977

Это написал не член Технического комитета.

anonymous
()
Ответ на: комментарий от anonymous

неа, не эталонный, ещё не кукарекали про юниксвэй.

Имей совесть - у скаженных ещё с прошлой новости пукан не зажил :-D

anonymous
()
Ответ на: комментарий от anonymous

отсутствие поддержки cgroups

А cgmanager, по-вашему, для чего накатали?

Пример

Спасибо! Лучшего подтверждения моих слов и придумать было сложно.

In other words, this debate is not actually about systemd vs. upstart in
the most obvious sense.  Rather, the question, assuming one has narrowed
the choices to those two contenders, is between adopting all the major
components of systemd including the init system, or adopting most of the
major components of systemd but replacing the init system with upstart.
...
I think this changes the nature of the discussion in some key ways.  We're
not really talking about choosing between two competing ecosystems.
Rather, we're talking about whether or not to swap out a core component of
an existing integrated ecosystem with a component that we like better.

Now, I am generally on the side that says loose coupling of ecosystems is
an inherent good.  However, I don't agree that it's such an inherent good
that we should disassemble things just for the sake of having disassembled
things.  At feature parity, and absent any compelling reason to swap
components, I think we should take the path of least resistance and use
the integrations that other people have already developed.

Теперь понимаете? Он в явном виде пишет, что не хотим, но выбираем путь минимального сопротивления.

Это написал не член Технического комитета.

А тот человек, на которого вы ссылаетесь, вообще ушёл из технического коммитета, и тоже больше не его член. О чём моя ссылка и свидетельствует.

anonymous
()
Ответ на: комментарий от anonymous

А cgmanager, по-вашему, для чего накатали?

Для того, чтобы systemd-logind работал. upstart этой функциональностью не пользуется.

Спасибо! Лучшего подтверждения моих слов и придумать было сложно.

Вот зачем вы разводите демагогию? Или вы просто недостаточно хорошо понимаете английский? Но это всё равно не оправдывает ваше избирательное цитирование.

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

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

If we do have a reason for doing this, we should seriously consider it.
А выше он на несколько экранов расписывает, почему upstart даже не «при прочих равных». Приведу несколько цитат:
I started this process with the expectation that systemd and upstart would be roughly evenly matched in capabilities. My expectation was that I would uncover some minor differences and variations, and some different philosophical approaches, but no deeply compelling differentiation.

To my surprise, that's not what happened. Rather, I concluded that systemd has a substantial technical advantage over upstart, primarily in terms of available useful features, but also in terms of fundamental design.
If I'm correct in my analysis of the community and ecosystem dynamics, I think upstart needs to show that it is a significantly better technical choice than systemd in order to warrant the additional project work that will be required to build on top of upstart. Given feature parity, I believe we should adopt systemd so that we can focus our efforts on interesting new problems rather than on redoing integrations that other people have already done.

My personal analysis did not show that upstart was significantly better than systemd, or even at feature parity. Rather, I believe it is currently trailing systemd substantially in multiple areas, some of which will require significant design changes.
И наконец вывод:
Given that, I believe systemd is the clear choice

А тот человек, на которого вы ссылаетесь, вообще ушёл из технического коммитета, и тоже больше не его член.

На момент выбора системы инициализации он всё ещё был членом ТК и ушёл лишь через полгода, и явно не из протеста против systemd, ибо он за него и голосовал. Вы же привели мнение совершенно левого человека, который в процессе выбора участия не принимал.

anonymous
()
Ответ на: комментарий от anonymous

Для того, чтобы systemd-logind работал. upstart этой
функциональностью не пользуется.

http://upstart.ubuntu.com/wiki/Cgroup

Но это всё равно не оправдывает ваше избирательное цитирование.

Вы хотели, чтобы я все 10 страниц его текста цитировал?

А выше он на несколько экранов расписывает, почему upstart
даже не «при прочих равных».

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

anonymous
()
Ответ на: комментарий от ioway

Плевать, она не работает как надо и вылизывают ее не один год и мощности растут и...

Что в лоб, что по лбу... Ещё раз, для идиотов: в подавляющем большинстве случае проблемы не в PulseAudio, а в кривых дровах алсы, которые забесплатно никто не хочет фиксить, а у тех полутора калек, а кого они есть нет денег нанять разработчика.

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

anonymous
()
Ответ на: комментарий от anonymous

А может, стоит послушать, что именно они говорят? Ну это так, если кому интересно.

Дык уже - тебе даже конкретную цитату с наездом привели на которую Леннарт отвечал. Если ты настолько туп, что даже гуглотранслейт не осиливаешь, то попроси - переведём.

Я тут эту тему развивать не стану в любом случае.

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

anonymous
()
Ответ на: комментарий от anonymous

Дык уже - тебе даже конкретную цитату с наездом привели на
которую Леннарт отвечал.

Ту цитату я и привёл, а потом ещё к ней же предложение докинул, отдельным сообщением. Можно было догадаться.

anonymous
()
Ответ на: комментарий от anonymous

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

Уже есть, благодаря другому анонимусу, см выше.

anonymous
()
Ответ на: комментарий от anonymous

Дык уже - тебе даже конкретную цитату с наездом привели на
которую Леннарт отвечал.

А, на которую отвечал, ну и в чём там наезд?

anonymous
()
Ответ на: комментарий от kernelpanic

А у меня pulseaudio работает без косяков.

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

anonymous
()
Ответ на: комментарий от Deleted

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

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

anonymous
()
Ответ на: комментарий от Deleted

хороший код очень легко читать. Там же плохо задокументированное говно.

Ты просто не умеешь читать :-D

anonymous
()
Ответ на: комментарий от anonymous

http://upstart.ubuntu.com/wiki/Cgroup

И? Читаем:

Before going into details about the proposed stanza and overall behaviour,
I'd begin by saying that contrary to some other init systems, our intent is solely
related to resource controls which is the main goal of cgroups. Process
grouping and tracking will remain unaffected by the addition of cgroup support. 
А если перейти на Launchpad:
[stgraber] work out the syntax of the cgroups stanzas for upstart: DONE
[stgraber] write spec: DONE
[jamesodhunt] implement cgroup support within upstart (talking to the cgroup manager): POSTPONED
[jamesodhunt] Write unit tests for cgroup support: POSTPONED
[jamesodhunt] Extend DEP-8 tests for cgroup support: POSTPONED
[jamesodhunt] get dbus upstream to support restoring connections from a socket on re-exec: POSTPONED
[jamesodhunt] Re-enable Upstart D-Bus activation (bug 1238514): POSTPONED
[jamesodhunt] Investigate making child handling fully async to ensure cgmanager cannot block PID 1: POSTPONED
[jamesodhunt] Implement IPv6 support for socket bridge (bug 942955): DONE
[jamesodhunt] Implement UDP support for socket bridge (bug 1265014): POSTPONED
[jamesodhunt] upstart should support systemd-style socket activation (debian bug 732179): POSTPONED
То есть предложено добавить поддержку cgroups, но только для управления ресурсами, дочерние процессы всё так же никто не будет контролировать. И даже это не реализовано, только спецификация написана.

Вы хотели, чтобы я все 10 страниц его текста цитировал?

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

Если вы ещё внимательнее прочитаете то, что процитировал я, то поймёте, что он не про апстарт говорит, а про системд с заменой основного пид-0 процесса на апстарт.

Во-первых, ничего подобного. Технические аргументы, приведённые Russ'ом, касаются конкретно upstart как init в сравнении с systemd как init; обвязка что для одного, что для второго всё равно от systemd, и в сравнении не участвовала.

И чем ему такое решение нравится больше, я процитировал тоже.

Если вы в приведённом фрагменте умудрились вычитать, что Russ'у больше нравится конфигурация с upstart как init, то у меня для вас плохие новости: вы недостаточно хорошо понимаете английский.

И именно к этому сейчас стремится убунта, пилящая всякие шимы.

Именно от этого сейчас уходит убунта, о будущем переходе которой на systemd было заявлено Марком.

anonymous
()
Ответ на: комментарий от Deleted

Отучайся говорить за всех. Тот же Патрик, например, отказался.

Он не отказался, он просто слоупок. Он пакетный менеджер-то лет 10 запилить не осиливал - так что приходи ещё лет через 10 - как раз раздуплится systemd накатить. Эх и славный баттхёрт будет напоследок :)

anonymous
()
Ответ на: комментарий от anonymous

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

Я лишь опровергал ваше утверждение, что cgmanager нужен исключительно для логинда. Как видите, нужен и для апстарта. Ну да, пока не реализовано, ок.

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

Вот этого не надо. Единственный вырез я пометил многоточием, и там было всего одно предложение, вот это:

Either way, we'll be running udev, logind, some systemd D-Bus services,
and most likely timedated and possibly hostnamed for desktop environments.

Технические аргументы, приведённые Russ'ом, касаются
конкретно upstart как init в сравнении с systemd как init;
обвязка что для одного, что для второго всё равно от systemd,
и в сравнении не участвовала.

Это не так, к примеру, он сравнивает там journald vs lbcd, и пр.

Если вы в приведённом фрагменте умудрились вычитать, что
Russ'у больше нравится конфигурация с upstart как init

Не совсем так.

Therefore, I believe the burden of proof is on upstart to show that it is
a clearly superior init system along some axis, whether that be
functionality or portability or flexibility or maintainability, to warrant
going to the effort of disassembling a part of the systemd ecosystem and
swapping in our own component.
Таким образом, он хотел бы видеть вместо системд-пид1 некий другой компонент, но считает, что апстарт пока не доказал, что достоин быть таковым. Но проблема ещё в том, что возьми сейчас системд - апстарт не получится вкорячить даже как альтернативную систему, и ему уже никак потом не доказать будет, что он достоин стать таковой заменой. И этот момент их беспокоит не меньше, ну не хотят они на один конкретный инит получать полную и безвозвратную завязку. Просто это уже в другом голосовании было.

Именно от этого сейчас уходит убунта, о будущем переходе
которой на systemd было заявлено Марком.

Как этот переход противоречит допиливанию шимов, и постепенному выпиливанию системд-пид1? Только не говорите, что это _вам_ я уже четвёртый раз одно и то же повторяю, надеюсь, то был другой анонимус...

anonymous
()
Ответ на: комментарий от vurdalak

И она не переставала быть лучшей.

Перестала с появлением PulseAudio

Просто её время прошло.

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

anonymous
()
Ответ на: комментарий от anonymous

Вот этого не надо. Единственный вырез я пометил многоточием, и там было всего одно предложение

Однако вы вырезали первый абзац раздела, в котором была вводная, из которой понятно, о чём речь, а также оставшуюся часть предпоследнего абзаца, из которого ясно, что он говорит чисто гипотетически, вместе с последним, где был вывод, ради которого всё выше (в данном разделе) и писалось:

Debian has
more than enough hard integration problems to solve without creating new
ones for ourselves unnecessarily.  But that's the key word: unnecessarily.
If we do have a reason for doing this, we should seriously consider it.

Therefore, I believe the burden of proof is on upstart to show that it is
a clearly superior init system along some axis, whether that be
functionality or portability or flexibility or maintainability, to warrant
going to the effort of disassembling a part of the systemd ecosystem and
swapping in our own component.
То есть нет никаких проблем с заменой systemd upstart'ом как PID 1, но только если будет доказано, что последний значительно лучше в этой роли.

Это не так, к примеру, он сравнивает там journald vs lbcd, и пр.

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

Во-вторых, сравнивалось удобство в управлении и отладке сервисов, что имеет самое прямое отношение к init, и что, действительно, в случае с systemd реализовано с помощью journal, аналога которому в upstart нет.

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

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

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

Как этот переход противоречит допиливанию шимов, и постепенному выпиливанию системд-пид1?

Так переход-то и состоит во впиливании systemd как PID 1! Остальными частями systemd (udev, logind...) upstart обмазался даже ещё до поднятия вопроса о системе инициализации в Debian.

Поймите, я как пользователь Debian следил за этой эпопеей с самого начала и большую часть того гигантского багрепорта читал чуть ли не в режиме live. Даже поучаствовал парочкой собственных сообщений. Прекратил следить лишь когда все вопросы окончательно решили и начался срач. Так что я хорошо осведомлён об истории и нюансах принятия решения в ТК, причём из первых рук, а не в пересказе журналистов от OpenSource.

anonymous
()
Ответ на: комментарий от anonymous

Вполне можно заниматься выпиливанием системд и оттуда, где он есть. Что и делает убунта.

О, клоун вернулся, я аж без тебя скучать начал :)

Вы соц опрос проводили? У дебиановцев спросите.

Проводили. По результатам опросов в дебьян по-умолчанию systemd, у Яна порван пукан а какой-то хитрый латинос стрижёт с хейтеров бабло, обещая весь дебьян форкнуть прямо на гитхаб :)

Вы дистростроитель чтоль?

Ага.

Можно узнать, в какой дистрибутив контрибьютите, и каков ваш вклад туда?

Debian, Ubuntu, Arch. Тестирование, написание systemd юнитов там, где они отсутствуют, баг-репорты в апстрим с просьбой добавить поддержку systemd.

Наняли разработчиков специально для этого, сделали systemd-shim, адаптировали cgmanager, собираются логид пилить...

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

anonymous
()
Ответ на: комментарий от targitaj

Эта... А куда все делись?

Не ссы, я с тобой :)

anonymous
()
Ответ на: комментарий от Deleted

кукушка хвалит петуха)

умерь ЧСВ, тебя не хвалят - над тобой смеются.

anonymous
()
Ответ на: комментарий от anonymous

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

Блин, купите этому животному словарик, кто-нибудь! Я уже ржать с придурка устал :-D :-D :-D

anonymous
()
Ответ на: комментарий от AS

А Windows - 90% контуперв... :-)

Бедняжка... заговариваться стал... это ж как пукан должен был рвануть, что аж моск зацепило... или он просто органически близко к эпицентру взрыва был расположен?

anonymous
()
Ответ на: комментарий от anonymous

Что в лоб, что по лбу... Ещё раз, для идиотов: в подавляющем большинстве случае проблемы не в PulseAudio, а в кривых дровах алсы, которые забесплатно никто не хочет фиксить, а у тех полутора калек, а кого они есть нет денег нанять разработчика.

Доооо, кривые дрова вальсы, кривые мантайнеры, все кривое...

Разработка ПО это _решение проблем_, и «кривое ABCD» - тоже одна из проблем, это понимают все кроме потного - ну вот собственно и результат: что ни проект то говно.

PulseAudio работает просто замечательно

Нет, замечательно работающая программа имеет 0 багрепортов. Точка.

ioway
()
Ответ на: комментарий от anonymous

Бред. Вполне можно заниматься выпиливанием системд и оттуда, где он есть. Что и делает убунта.

Убунта наняла разраба на фултайм - и он будет пилить сам системд.

Вы соц опрос проводили? У дебиановцев спросите.

Дебиановцы опрос проводили.

Перл... Вы дистростроитель чтоль? Можно узнать, в какой дистрибутив контрибьютите, и каков ваш вклад туда? А если вы не дистростроитель - кого волнует, что вас устраивает?

Вообще-то я не напрягусь и быть дистростроителем. Благо именно этим я и развлекался в свободное время. Но мне даже и суетиться не надо - все идет так, как мне нужно.

Вам уже сто раз было сказано, что убунта этим и занимается. Наняли разработчиков специально для этого, сделали systemd-shim, адаптировали cgmanager, собираются логид пилить... Вы, видимо, только самого себя слышите?

http://www.markshuttleworth.com/archives/1316
Марк сказал, что больше пилить systemd-shim не будут. И перейдут на чистый systemd.

Поучите дебиановцев и гентушников свободе, которые с этим системд уже задолбались. Пока они там голосования проводят, вы бы им про свободу вбрасывали, а то сами по форумам только и мастер орать. :)

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

kir2yar
()
Ответ на: комментарий от ioway

Нет, замечательно работающая программа имеет 0 багрепортов. Точка.

И не существует. ))
Ребята, может стоит посмотреть на мир не через розовые очки?
Багтрекер для маленьких, но нужных вещей.
http://savannah.gnu.org/bugs/?func=browse&set=open&group=coreutils
Мем-лик в cp: http://savannah.gnu.org/bugs/?23023

Баги в багтрекере говорят только о том, что проект жив.

kir2yar
()
Ответ на: комментарий от kir2yar

Дебиановцы опрос проводили.

Где голос core kernel developer'a - равнялся голосу мантайнера пакета фортунок. Абуеть какой объективный опрос.

ioway
()
Ответ на: комментарий от ioway

Где голос core kernel developer'a - равнялся голосу мантайнера пакета фортунок. Абуеть какой объективный опрос.

Ну, дак, демократия и справедливость. А ты чего хотел?
Вообще, да, технический комитет дебиана превратился в сборище бюрократов... Однак, голосование прошло.

kir2yar
()
Ответ на: комментарий от ioway

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

Отсюда резонный встречный вопрос: а не пойти ли тебе на хрен?

intelfx ★★★★★
() автор топика
Ответ на: комментарий от kir2yar

И не существует. ))

Не существует, но близкие к этому состоянию проекты есть.

Ребята, может стоит посмотреть на мир не через розовые очки?

Я не смотрю на мир через розовые очки, даже наоборот - они у меня очень черные. Только почему-то в большинстве случаев когда указывают на явные ошибки - люди честно признаются «Да, косяк есть. Да надо поправить, но ресурсов не хватает. Если можете помочь - вот посмотрите план, может что нибудь придумаем». Нооооооо ни в коем случае ни с пульсой ни с системд. Никакого плана, никаких целей, все кто не системд - п№дарасы. Видел уже такие проекты и коммерческие и не очень - все кончилось плохо.

Так что я лучше запасусь попкорном и посмотрю как за дело возьмутся БСДшники.

ioway
()
Ответ на: комментарий от intelfx

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

Какие у тебя фантазии... кстати это объясняет причины твоего поведения.

Отсюда резонный встречный вопрос: а не пойти ли тебе на хрен?

Нет наоборот, я буду продолжать отравлять твое «виртуальное» шествие по лору.

ioway
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.