LINUX.ORG.RU

Февральские тезисы о планах развития systemd

 ,


2

4

На прошедшей конференции FOSDEM Леннарт Поттеринг огласил некоторые перспективы развития systemd:

  • Интеграция в systemd загрузчика gummiboot, поддерживающего технологию UEFI Secure Boot.
  • machined — менеджер регистрации виртуальных машин, спроектированный под впечатлением от Solaris Zones.
  • В подсистеме nspawn и смежных с ней ожидается больше возможностей для управления контейнерами, например, journald сможет собирать логи не только с хоста, но и с контейнеров.
  • Уже в следующей версии ожидается улучшенная поддержка Btrfs (подразделы и снапшоты Btrfs планируется использовать для изоляции отдельных приложений).
  • Поддержка HiDPI и Юникода в consoled.
  • Сервис-ориентированный фаерволл: можно будет задавать правила в привязке не к номерам портов, а к именам процессов.
  • Отпадёт нужда указывать путь к юниту для systemctl-cat; systemctl-edit позволит редактировать юниты и после сохранения изменений автоматически перезапускать соответствующие сервисы.
  • nss-getmyhostname — функция для получения имени хоста на stateless-системах.
  • Утилита ping gateway позволит автоматически определить все доступные сетевые интерфейсы и проверить их статус командой ping.
  • Развитие networkd и собственной библиотеки для работы с DHCP (совместимой с dhcpv4 и dhcpv6).
  • Комбинирование nspawn и networkd позволит легко конфигурировать сеть для контейнеров.
  • Создание средств для широкого системного аудита, интегрированных в journald. Например, станет возможным логировать все системные вызовы к файлу /etc/passwd.
  • Движение в сторону stateless-систем, у которых только /usr доступен на чтение и запись, а /etc и /var будут автоматически заполняться systemd.
  • journald-remoting — удалённая работа логгера через HTTP. Поддержка в journald моделей pull и push: при pull выполняется запрос HTTP GET для получения потока JSON, а при push данные передаются в другой экземпляр journald при помощи HTTP POST.
  • Возможность определения для сервисов минимальных пространств имён и sandbox-изоляции: доступ к некоторым разделам и каталогам только на чтение, сокрытие устройств в /dev, приватный /tmp для каждого сервиса, и др.
  • timesyncd в качестве замены ntpd.
  • Автоматическое определение разделов GPT, не нуждающееся в указании их в fstab.
  • Поддержка перезапуска демонов без потери их состояния (посредством сохранения оного на диск).

>>> Подробности



Проверено: Shaman007 ()
Последнее исправление: ymn (всего исправлений: 1)

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

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

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

И это тоже характерный признак, сразу два. Первое. Прийти в чужой монастырь и начать учить, не разбираясь в предмете. Вы программируете на sh? Вы сами сказали, что нет. Так какого черта вы учите тех, кто программирует? Не понятно.

Во первых - программирую и я говорил об этом. Хотя программирование на sh - это не совсем программирование. В лучшем случае - скриптоложество.
И многие проблемы шела - понятны. Просто потому-что он ориентирован/заточен на работу с вводом пользователя, а не выполнение скриптов.
К примеру: [ - является отдельной программой, лежит (у убунты, к примеру) в /usr/bin, а не элементом языка.
Если сделать симлинк test -> FileExists - то вполне можно будет писать: if FileExists -f /blabla
Проблема в том, что метод группировки аргументов программы у баша не самый интуитивный.
/bin/sh -c «echo 123» к примеру еще понятно
/bin/sh -c 'asterisk -x «sip show channels»' - уже немного напряжно
А если добавить третий и четвертый уровень вложенности... Уже как-то припекать начинает. Да и экранирование кавычек адски надоедает.

Кстати, всплыла новая проблема. «[ - является отдельной программой, лежит (у убунты, к примеру) в /usr/bin»

А вот теперь, смеха ради, представим, что у меня /usr на другом компьютере. Монтируется через сеть. Как в таком случае поведут себя скрипты, в которых используется «[»? Включая те, что инициализируют сеть.
Вывод - ВСЕ системы, у которых coreutils находятся в /usr и используется скрипт-ориентированный инит, не позволяют держать этот /usr на удаленном компьютере. По крайней мере, без серьезной ручной доработки.
Впрочем, надо признать, что проблема еще и в том, что правила udev и systemd юниты тоже находятся там-же. Конечно, это можно легко исправить на этапе конфигурации udev да systemd. Просто сказав ему собираться не в /usr а в /. А в скрипт-ориентированных инитах можно переписать все скрипты, которые исполняются до инициализации сети и монтирования /usr...

FileExists() { test -e «$1» ; return $? } и пользоваться?

Да я примерно так и делаю. Проблемы возникают когда приходится разбираться в чужих скриптах. Честно - тот-же питон намного проще отладить.

Вот в том и дело. «Делать для себя как удобнее» и «делать систему общего назначения, удобную для существующей индустрии»

Существующая индустрия приняла. Пользователям пофиг. Это рядовые админы жалуются.

Таких «вещей» systemd включает сотню, из которой десяток будет хорошими идеями, которые вообще незачем засовывать в systemd и вообще в какой-либо инит,

Да никто в саму инит-систему системд всякий хлам не включает. Сколько раз повторяю, ссылки привожу, в документацию тыкаю все едино. Прям селективная слепота.
Включают в проект, который состоит отнюдь не из одного файла.
http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/
Вот. Последний раз отвечаю на этот аргумент не называя собеседника тупым идиотом.

Увы, нет. В блог виновника торежства я иногда заглядываю, и заметки его читаю в оригинале.

Ну, как-бы давай ссылку где LP неконструктивен.

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

Кстати, про proftpd, его лучше настроить так, чтоб ни одна б... его не перезапускала. Т.е. тут лучше syslog и не париться.

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

Все проблемы решаются переносом coreutils и костылём на баше.

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

Это одна сущность.

Определение сущности и технические проблемы от того, что она одна, в студию.
Системд - так-то состоит из кучи исполняемых файлов, каждый из которых делает свое маленькое дело и общаются через dbus. Причем у многих из них, api документирован и помечен как стабильный.

при помощи гвоздей, скотча и клея, а не подсоединено на проводах через стандартизированные разъёмы.

Dbus - достаточно стандартная вещь. Есть даже консольные утилиты по работе с дбасом. Те, есть возможность дружить с shell скриптами те компоненты systemd у которых api уже стабилизировали.

А вот вязанки скриптов, как тут человек сказал про invoke-rc.d уже что-то за гранью фантастики. Скрипт, который запускает скрипт, который запускает другой скрипт два раза.

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

Наоборот. Проблема как раз в том, что invoke-rc.d не передаёт restart, а запускающий скрипт починили только для этой команды.

И что мешает

invoke-rc.d proftpd stop && invoke-rc.d proftpd start
засунуть в logrotate вместо restart ?

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

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

Вот. Последний раз отвечаю на этот аргумент не называя собеседника тупым идиотом.

Я вам уже устал объяснять на пальцах, на словах, на молекулярном уровне: логически отдельные сущности должны лежать в логически отдельных проектах. В логически отдельных — это значит отдельные репозиторий, версионирование, документация, баг-трекер.

Если вы этой простой мысли не понимаете, вам просто нечего делать в разработке ПО.

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

А кого идиотом называть — ваше личное дело. Только имейте ввиду, что называя собеседника идиотом, можно оказаться идиотом самому.

Во первых - программирую и я говорил об этом. Хотя программирование на sh - это не совсем программирование. В лучшем случае - скриптоложество. И многие проблемы шела - понятны. Просто потому-что он ориентирован/заточен на работу с вводом пользователя, а не выполнение скриптов. К примеру: [ - является отдельной программой, лежит (у убунты, к примеру) в /usr/bin, а не элементом языка. Если сделать симлинк test -> FileExists - то вполне можно будет писать: if FileExists -f /blabla Проблема в том, что метод группировки аргументов программы у баша не самый интуитивный. /bin/sh -c «echo 123» к примеру еще понятно /bin/sh -c 'asterisk -x «sip show channels»' - уже немного напряжно А если добавить третий и четвертый уровень вложенности... Уже как-то припекать начинает. Да и экранирование кавычек адски надоедает.

Еще раз по буквам: это стандартный интеграционный язык. Да, плохой. Да, с ужасным синтаксисом и семантикой. Да, читая раздел Shell & Utilities в SUS, хочется дать кому-нибудь в рожу. Но другого СТАНДАРТНОГО языка сейчас нет.

Если вы хотите сделать благое дело, разработать такой язык и внедрить его в существующие дистрибутивы и в стандарты, замечательно. Благое и очень трудоемкое дело. Но вы ж не этого желаете. Вы думаете, что если засунуть голову в ж^W, простите, в песок, и притвориться, что sh никогда не существовало, то вам станет лучше. Не станет. Потому что sh или его аналог всё равно нужен. Сколь-угодно развесистыми ini-файлами вы не перекроете потребность иметь такой язык.

И какое отношение все эти рассуждения о свойствах sh имеют к задаче супервизинга демонов? Ровным счётом никакого.

Кстати, всплыла новая проблема. «[ - является отдельной программой, лежит (у убунты, к примеру) в /usr/bin»

А вот теперь, смеха ради, представим, что у меня /usr на другом компьютере. Монтируется через сеть. Как в таком случае поведут себя скрипты, в которых используется «[»? Включая те, что инициализируют сеть. Вывод - ВСЕ системы, у которых coreutils находятся в /usr и используется скрипт-ориентированный инит, не позволяют держать этот /usr на удаленном компьютере. По крайней мере, без серьезной ручной доработки.

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

Проблемы раскладки файлов в конкретных дистрибутивах — это проблемы раскладки файлов в конкретных дистрибутивах. И снова, при чем тут супервизор демонов? То вы не можете разделять уровни абстракции, то теперь вы не можете разделять темы обсуждения...

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

оот молодец!

Два бурбона этому господину в шляпе Блэкмора!

Додумался пропиарить вику (твое создание?) нейтрализации этой заразы.

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

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

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

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

Всю эту беду накликали десктопостроители со своим dbus-ом. Который, кстати, первый начал. Ну это я типа только что снял тяжкий груз вины с systemd и переложил его на плечи d-bus.
Потому что пресловутые принципы UNIX поломал именно d-bus. Интерфейс ни разу не текстовый, множество функций - один сервис ну и т.д.
А почему? Потому что мультикаста нормального не было. Да-да. Вся эта ботва исключительно из-за мелочей, которыми мы долго пренебрегали, потому что серверам это не очень-то и нужно, а десктопам - критично. Десктоп - это дофига служб самого разного назначения, с ветвленым мессаджингом между ними. И да, нужна еще служба well known services. Ну типа DNS, но в масштабах исключительно локалхоста и с возможностью при необходимости кого-нибудь пнуть, чтобы тот поднял требуемый сервис.
Паттернов обмена сообщениями не так много. Их, к примеру, прекрасно реализовали в zmq. Проблема в том, что нужны не библиотеки, а утилиты прикладного уровня, связанные в решение.
Десктопостроители запилить нечто подобное принципиально не способны, в силу менталитета, а нам пофиг.
Ну а теперь прорвало канализацию, клюнул жареный петух, на почве d-bus вырос гриб systemd и нам уже теперь не пофиг, но ситуация уже не плановая, а совсем даже авральная. Не люблю я этого.
Ну и ладно, разгребем как-нибудь.

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

Логически это одна сущность. PID1 systemd бессмысленен без обвязки, а обвязка бессмыслена без использования PID1 systemd.

Если бы еще был смысл в sysvinit или ruint без обвязки...
Давай возьмем sysvinit/runit, приплюсуем к нему баш и весь coreutils, все шеллскрипты и посмотрим, кто толще?

Дело в том, что и sh и coreutils - это отдельные сущности, которые используются и без относительно к sysvinit

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

И да, нужна еще служба well known services. Ну типа DNS, но в масштабах исключительно локалхоста и с возможностью при необходимости кого-нибудь пнуть, чтобы тот поднял требуемый сервис.

Ты только что описал d-bus.

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

Кто запрещает написать компактных два скрипта, которые будут делать эту работу на отлично. Плюс должен быть заложен принцип стандартов Unix'а.

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

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

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

Ну а теперь прорвало канализацию, клюнул жареный петух, на почве d-bus вырос гриб systemd и нам уже теперь не пофиг, но ситуация уже не плановая, а совсем даже авральная.

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

Ну и ладно, разгребем как-нибудь.

И с этим согласен.

Разум когда-нибудь победит. (с)

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

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

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

Вот.
Ты даже не понимаешь.
d-bus делает не только это.
Он не только one point to know about everything, он еще и one point to access everything, он еще и транспорт. И протокол. И протокол этот намертво связан с ним самим. И протокол этот НЕ текстовый.

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

Я прекрасно понимаю, что такое d-bus. В связи с чем вопрос — а что, должно быть как-то по-другому? Зачем там текстовый шинный протокол? Зачем там децентрализация (или что ты подразумеваешь под противоположностью «one point»)?

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

Я вам уже устал объяснять на пальцах, на словах, на молекулярном уровне: логически отдельные сущности должны лежать в логически отдельных проектах. В логически отдельных — это значит отдельные репозиторий, версионирование, документация, баг-трекер.

А смысл? Это один проект, системд. Или, по твоему, тот-же заббикс не комильфо? А то что, у него сборщик данных zabbix_agent находится в том-же проекте, что и совершенно другая по задачам сущность - zabbix_server?

Есть ли технические причины по которым все, что сейчас находится в проекте systemd, нужно раскидать по разным проектам? Кроме чужого чувства эстетики и эмоциональных криков?

Еще раз по буквам: это стандартный интеграционный язык. Да, плохой. Да, с ужасным синтаксисом и семантикой. Да, читая раздел Shell & Utilities в SUS, хочется дать кому-нибудь в рожу. Но другого СТАНДАРТНОГО языка сейчас нет.

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

Если вы хотите сделать благое дело, разработать такой язык и внедрить его в существующие дистрибутивы и в стандарты, замечательно.

Что-бы очередная толпа Veteran Unix Admins начала собирать биткойны на килера для меня? Ибо они старые дедушки, им новое учить тяжело, шелл был с 80ых годов... Традиции.

Тот-же луа грозятся встроить в ядро, если уже не встроили. Давай его использовать как стандартный?

И какое отношение все эти рассуждения о свойствах sh имеют к задаче супервизинга демонов? Ровным счётом никакого.

Для супервизинга демонов - никакого. Однако мы сейчас рассуждаем о запускалки скриптов, которая без шела даже зависимости не может, не так-ли?

Вообще-то ни SUS, ни FHS, никоим образом не специфицируют, где толжны лежать utilities, кроме того, что они должны быть доступны в PATH.

Это да.

Проблемы раскладки файлов в конкретных дистрибутивах — это проблемы раскладки файлов в конкретных дистрибутивах. И снова, при чем тут супервизор демонов? То вы не можете разделять уровни абстракции, то теперь вы не можете разделять темы обсуждения...

Ну то не наезд был, а просто забавное наблюдение. Я делал как-то сетевую загрузку той-же убунты. Но я собирал образ системы в squashfs и у меня, понятное дело, /usr был там-же.
Ну, хотелось-бы иметь инит-систему, которая не падает в обморок при стандартном, но не распространенном расположении /usr. Но это лечится. В обоих случаях через initramfs.


Кстати, а вот есть интересная идея!
Памяти сейчас у людей достаточно, а вот ssd дисками не каждый может похвастаться. Что если собрать какой-либо минималистический дистрибутив, работающий примерно так:

Системные вещи, вроде иксов, дбаса, удева, либгтк/куте и прочее, прочее... Собрано в squashfs образ и при запуске компа копируется на рамдиск.
Тяжелый пользовательский софт, типа того-же опенофиса, файрфокса, игр хранится на обычном жестком диске. Документы - тоже само-собой.

При обновлении системной части - squashfs образ пересобирается.

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

Минимальный образ убунты, который я собирал в squashfs занял у меня где-то 450метров.
Там был файрфокс, опеноффис (самое тяжелое), всякие админские тулзы (нет им числа), маны на все.
С рамдиска работало оно просто реактивно.

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

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

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

Скажи сам.

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

А смысл? Это один проект, системд. Или, по твоему, тот-же заббикс не комильфо? А то что, у него сборщик данных zabbix_agent находится в том-же проекте, что и совершенно другая по задачам сущность - zabbix_server?

zabbix_agent немыслим без самого zabbix. в то же время, systemd поглощает совершенно не связанные логически сущности. например, udev. или пресловутый journald — не вижу ни единой причины, почему эти проекты должны быть хоть сколько-нибудь привязаны к systemd: journald это такая хитрая замена сислогу, а udev вообще отдельная сущность (таковым он и родился, но, увы, перерос в какого-то мерзотного монстра, после обновления которого, как и с systemd, вечно приходится копаться руками и что-то исправлять, потому что разработчики сильно ретивые).

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

Зачем придумывать D-Bus заново, или невозможно сделать два скрипта на баше, которые будут управлять взаимодействием процессов.

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

Должны быть:
- одна служба для поиска и запуска нужной службы. Что-то вроде inetd. - транспорт, с поддержкой паттернов обмена сообщениями. Мультикаста в частности. С поддержкой работы стандартных пайпов.
- документированный текстовый протокол(ы) обмена данными
Тогда это будет решение, а не непонятная монолитная хрень с лапочками сам знаешь где.

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

а udev вообще отдельная сущность

Связь на уровне задачи. А задача простая - запустить компьютер и все необходимое для работы прикладного софта/служб. Обеспечить все необходимое для работы этого компьютера, прикладного софта и служб.
Соответственно - системд именно эту задачу выполняет.
Нужно журналирование на этапе, когда сислог еще не поднялся - вот вам журналид. Нужна инициализация устройств - вот вам завязка на удев. Нужна сокет-активация - готово.

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

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

Если у вас все работает, вам повезло. http://habrahabr.ru/post/113482/

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

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

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

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

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

Я бы не отказался от системы рекупирации кислорода. Так, что бы зарядил встроенный аккум / поставил фильт и углекислый газ, прям в крови, распадается на кислород и углерод. Разумеется с соблюдением всех норм концентрации обоих веществ в крови.

Правда на счет ануса... У анонимусов странная фантазия.

В любом случае: не нравится системд - просто не используй его. Есть тот-же диван, есть кучка дистрибутивов без системд. Да и runit/sysvinit по словам местных - весьма простой и понятный, можешь даже сам себе на комп запилить.
(в простейшем случае с помощью apt-get)

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

Мультикаст, например.
Ядро не реализует паттерны обмена сообщениями искаропки.
Знаете как запилить на баше? С удовольствием почитаю. Без иронии.

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

Это вам не байткод.

Исходники которого можно скачать с официального сайта. Да и сам системд содержит массу крутых инструментов.
Плюс такая детская болячка у него тупо отсутствует.

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

И да, это возможно, но паттерны не нужны, так как можно по-другому реализовать.

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

есть кучка дистрибутивов без системд

Гыгы, да ладно, прекрати.
Серьёзные - старый дебиан и salix. С остальным совсем стрёмно связываться.

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

Серьёзные - старый дебиан и salix. С остальным совсем стрёмно связываться.

Ну, из десктопных есть хорошие. Та-же генту ничего-так на десктопе.
Из серверных, пока дебиан, в котором можно просто сделать apt-get install sysvinit.
В общем, никакого принуждения.

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

Связь на уровне задачи.

На уровне задачи связано всё.
Давайте запилим один бинарь?
Чтоб там было все - ядро, иксы, шеллы, системд, гэ, цэ, любимый оконный менеджер...
Жмакнул кнопку - все загрузилось - и вот оно счастье... на уровне задачи...
И никакого геморроя с инитами-хренитами, никаких тебе возможностей и свобод - сразу Ш не Г искаропки, цветовая схема от ЛП, единственно правильная, музычка проверенная и трилогия «терминатор», скомпилированная прямо в этот бинарь насмерть.
Смотри, слушай, редактируй - не хочу.
Хотя, насчет «редактируй» - это я , пожалуй, погорячился...

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

Есть даже консольные утилиты по работе с дбасом.

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

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

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

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

FileExists() { test -e «$1» ; return $? } и пользоваться?

Да я примерно так и делаю.

Знаю извращенца, которому так же не нравился синтаксис шелла. Так он себе tcc поставил и скрипты на сях писал. В начале файла только #!/usr/bin/tcc -run надо было написать, а дальше чистейший C. И вообще ни разу человек не жужжал. Что мешает поставить нужный интерпретатор/компилятор и написать себе все инит скрипты на любимом языке, при этом не принуждая всех остальных любить то, что у тебя получится?

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

Что мешает поставить нужный интерпретатор/компилятор и написать себе все инит скрипты на любимом языке, при этом не принуждая всех остальных любить то, что у тебя получится?

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

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

d-bus хоть куда перенеси - хоть в юзерспейс, хоть в ядро, хоть в системд его влей - он все равно все тот же dbus с теми же архитектурными проблемами.
Второй вопрос - зачем нужны текстовые интерфейсы. Отвечаю. Обрати свой взор на журналд. Обрати еще раз. Медитируй, вникай, думай, изучай заявленную мегафункциональность и реальные траблы с которыми сталкиваются те, кто использует это поделие.
Поразмысли о причинах возникающих ... мнээээ... недоразумений.
Я почему-то думаю, что у тебя получится сделать некие разумные предположения.
Знаешь, системдэ не первая серебряная пуля, которую отливали на моей памяти. И знаешь, я тоже велся на всякую хрень, и даже с энтузиазмом. Так что понимаю и не осуждаю.
Голову только не выключай. Удачи.

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

И что мешает

Состояние гонки, сказано же. Дело в том, что в конечном итоге вызывается start-stop-daemon (да, в конечном итоге демоном управляет сишный бинарник, это же так юниксвейно, когда сишный init вызывает скрипт на баше, который проверяет возможность запуска другого скрипта на баше и корректность передаваемых ему параметров с помощью десятка других сишных утилит, потом этот баш скрипт запускает башскрипт, который опять с помощью десятка сишных утилит сгенерирует правильную строку запуска сишной программы, которая и запустит/остановит демона, а когда сишный systemd парсит конфиг и на его основе запускает/останавливает демона — это так неюниксвейно и вообще рак, убивающий линукс), который по-умолчанию после посылки сигнала сразу завершается. Ну вызвал ты invoke-rc.d proftpd stop, демон пошёл завершаться, но до вызова invoke-rc.d proftpd start ещё не завершился и pid-файл не удалил, start-stop-daemon увидел неудалённый pid-файл и прервал старт. Корявое решение — добавить sleep между стопом и стартом, правильное решение — настроить таймауты параматра --retry для start-stop-daemon, но речь не о косяках мантейнеров, а о том, что за годы, обходя ограничения sysvinit, нагородили столько велосипедов и подпорок, что они уже стали друг дружке мешаться.

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

А смысл? Это один проект, системд. Или, по твоему, тот-же заббикс не комильфо? А то что, у него сборщик данных zabbix_agent находится в том-же проекте, что и совершенно другая по задачам сущность - zabbix_server?

Есть ли технические причины по которым все, что сейчас находится в проекте systemd, нужно раскидать по разным проектам? Кроме чужого чувства эстетики и эмоциональных криков?

Диалог с аноноим содержит исчерпывающую аргументацию:

Связь на уровне задачи.

На уровне задачи связано всё. Давайте запилим один бинарь? Чтоб там было все - ядро, иксы, шеллы, системд, гэ, цэ, любимый оконный менеджер... Жмакнул кнопку - все загрузилось - и вот оно счастье... на уровне задачи... И никакого геморроя с инитами-хренитами, никаких тебе возможностей и свобод - сразу Ш не Г искаропки, цветовая схема от ЛП, единственно правильная, музычка проверенная и трилогия «терминатор», скомпилированная прямо в этот бинарь насмерть. Смотри, слушай, редактируй - не хочу. Хотя, насчет «редактируй» - это я , пожалуй, погорячился...

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

Тот-же луа грозятся встроить в ядро, если уже не встроили. Давай его использовать как стандартный?

Луа тут совсем не ку-ку. Это еще один ужас на крыльях ночи, не дай бог, это говно попадёт в стандарты. В ядре может и имеет смысл где-то применять байт-код в драйверах, но Луа дорос до состояния «можно попробовать внедрить» только в последней версии. До этого в нём даже не было целочисленной арфметики. А уж ХОРОШЕЙ целочисленной арифметики в нём не будет, наверное, никогда. В Си её — хорошей, — допустим, тоже нет. Но Си — зло привычное. А это зачем?

А на уровне инструментальных средств эта луа нахрен не нужна. Задачи, решаемые на этом уровне, структурно обычно требуют не наплодить кучу классов-таблиц, а быстренько попарсить опции и запустить чего нужно. Тут требуется что-то типа TCL, но не упоротого. TCL исправляет абсолютно ВСЕ факапы sh в синтаксисе. Из TCL кода можно доставать нужные данные, не занимаясь полноценной интерпретацией или занимаясь ею частично. Можно в одном и том же формате хранить и логику, и настройки и парсить универсальным способом. Это вин. Зато он добавляет еще кучу факапов в стандартную библиотеку, до уровня полной бесполезности языка. «tool construction language», не умещий fork() и exec(), — это fail.

Так что по СОВОКУПНОСТИ свойств sh сейчас без вариантов, как и 20 лет назад.

Это, кстати, такой «прогресс». Вы тут про «задачу запуска системы рассуждаете», а люди 25 лет не могут изобрести ничего приличнее sh. Тут не до systemd-ев ваших. :D

Для супервизинга демонов - никакого. Однако мы сейчас рассуждаем о запускалки скриптов, которая без шела даже зависимости не может, не так-ли?

runit — супервизор демонов. Остальное его не волнует. Выше аноним вам писал, у вас в ./run может быть что угодно. Пишете в начале файла #!/bin/my-cool-interp, и вот у вас уже работает не ужасный sh, а стильный-моложёдный my-cool-interp. А там уж внутри файла хоть ини-файлы, хоть луа, любой ваш каприз.

Системные вещи, вроде иксов, дбаса, удева, либгтк/куте и прочее, прочее... Собрано в squashfs образ и при запуске компа копируется на рамдиск. Тяжелый пользовательский софт, типа того-же опенофиса, файрфокса, игр хранится на обычном жестком диске. Документы - тоже само-собой.

При обновлении системной части - squashfs образ пересобирается.

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

кажется, кто-то делал что-то подобное для генты. Да и разве нет подобных решений? Puppy Linux, или как его там. Система гразится со squashfs. Если нужен дополнительный софт, то поверх неё каскадно монтируется дополнительные squashfs. Всё это счастье может быть полностью stateless: нажал reset, и снова в чистой системе. Если надо обновиться, образы заменяются целиком на новые.

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

Это, кстати, такой «прогресс». Вы тут про «задачу запуска системы рассуждаете», а люди 25 лет не могут изобрести ничего приличнее sh. Тут не до systemd-ев ваших. :D

Вы провоцируете написание bashdс с личным набором coreutilsd.

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

Вы провоцируете написание bashdс с личным набором coreutilsd.

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

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