LINUX.ORG.RU

systemd 216

 , ,


1

2

systemd — это менеджер системы и сессий для Linux. systemd совместим со скриптами инициализации SysV и LSB. Он предоставляет возможности агрессивного распараллеливания, использует для запуска сервисов сокеты и D-Bus активацию, позволяет запускать демоны по требованию, реализует транзакционную зависимостную логику управления сервисами, отслеживает процессы с использованием Linux cgroups, поддерживает создание снимков и восстановление, а также заведует монтированием и точками автомонтирования.

Это мажорный выпуск. Помимо прочих изменений, systemd-resolved теперь гармонично дополняет распознаватель заглушек кэширования DNS и LLMNR.

  • timedated больше не читает имена юнитов реализации NTP из /usr/lib/systemd/ntp-units.d/*.list. Альтернативная реализация NTP добавляет
    Conflicts=systemd-timesyncd.service
    в их юнит-файлы, заменяя собой функциональность NTP systemd по умолчанию.
  • systemd-sysusers получила новый тип строки «r» для настройки того, из каких диапазонов UID/GID выделять системных пользователей/группы. Строки типа «u» теперь могут добавлять дополнительную колонку для обозначения домашней директории создаваемого пользователя. Кроме этого, systemd-sysusers теперь может опционально считывать пользовательскую информацию из STDIN вместо файла. Это полезно вызове её из предустановочных скриптлетов RPM, которым нужно создать пользователей перед установкой первого файла RPM, так как этим файлам может требоваться владение этими пользователями. Новый макрос RPM %sysusers_create_inline представлен именно для этой задачи. systemd-sysusers теперь обновляет теневые файлы наряду с базами пользователей/групп, что улучшает совместимость с некоторыми инструментами, например, grpck.
  • Ряд шинных API PID 1 теперь опционально запрашивает у PolicyKit, предоставить ли доступ считающимся непривилегированными клиентам при определённых условиях. Имейте в виду, что интерактивная аутентификация в данный момент пока не поддерживается, но в конечном счёте ожидается добавление и её.
  • /etc/machine-info теперь обладает новыми полями для настройки среды развёртывания машины, а также месторасположения машины. hostnamectl обновлён и снабжён новой командой для обновления этих полей.
  • systemd-timesyncd обновлён до автоматического запроса информации о NTP-сервере у systemd-networkd, который можно обнаружить по DHCP.
  • systemd-resolved теперь включает распознаватель заглушек кэширования DNS и полную реализацию разрешения имён LLMNR. Добавлен новый модуль NSS «nss-resolve», позволяющий использовать собственный «nss-dns» glibc для обнаружения имён хостов через systemd-resolved. Имена хостов, адреса и произвольные RR'ы можно распознавать через D-Bus API systemd-resolved. В отличие от внутреннего распознавателя glibc, systemd-resolved умеет работать с многодомными системами и удерживает DNS-сервера и кэши отдельно и поинтерфейсно. Запросы посылаются одновременно на все интерфейсы, имеющие настроенные DNS-сервера, для корректной обработки VPN и локальных LAN, которые могут распознавать отдельные наборы доменных имён. systemd-resolved может запрашивать информацию о DNS-серверах у systemd-networkd автоматически, который, в свою очередь, может находить её по DHCP. Нововведённый инструмент «systemd-resolve-host» можно использовать для запроса логического DNS у resolved. systemd-resolved реализует IDNA и автоматически использует IDNA или кодировку UTF-8 в зависимости от того, используется ли в качестве транспорта классический DNS или LLMNR. В следующих выпусках планируется добавить в systemd-resolved реализацию DNSSEC и mDNS/DNS-SD.
  • Добавлен новый модуль NSS nss-mymachines, автоматически распознающий имена всех локально зарегистрированных контейнеров по соответствующим IP-адресам.
  • Добавлен новый клиентский инструмент для systemd-networkd — «networkctl». В настоящий момент он полностью пассивен и запрашивает сетевую конфигурацию у udev, rtnetlink и networkd, предоставляя её пользователю дружественным способом. В будущем планируется расширить его до полноценной утилиты для управления networkd.
  • .socket-юниты получили новую настройку DeferAcceptSec=, управляющую sockopt ядра TCP_DEFER_ACCEPT для TCP. Аналогично, для управления TCP Keep-Alive добавлены KeepAliveTimeSec=, KeepAliveIntervalSec= и KeepAliveProbes=. Также поддерживается отключение алгоритма Nagle для TCP (NoDelay=).
  • logind обучен новому типу сессий «web» для использования в проектах наподобие Cockpit, регистрирующих web-клиентов как PAM-сессии.
  • Юниты-таймеры с как минимум одной настройкой OnCalendar= теперь будут запускаться только после достижения timer-sync.target. Таким образом, они не будут проходить перед подстройкой системных часов локальным NTP-клиентом или чем-то подобным. Отчасти это полезно на встраиваемых системах без RTC, запускающимся со сбитыми системными часами.
  • Ключ systemd-nspawn --network-veth= теперь приводит к стабильным MAC-адресам как на внешней, так и на внутренней стороне соединения.
  • systemd-nspawn получил новый ключ --volatile= для запуска экземпляров контейнеров с незаполненными /etc или /var.
  • Клиентский код kdbus обновлён для использования новой подсистемы Linux 3.17 memfd вместо старой, kdbus-специфичной.
  • DHCP-клиент и -сервер systemd-networkd теперь поддерживают FORCENEW. Также есть новые параметры конфигурации для настройки клиентского идентификатора поставщика и режима вещания для DHCP.
  • systemd больше не будет уведомлять ядро о текущем часовом поясе, так как это в любом случае неверно и колоритно, поскольку ядру неведом DST и подобные понятия. Как следствие, временные метки FAT будут всегда считаться UTC, примерно как это уже делает Android. Помимо этого, когда RTC настроены на локальное время (отличное от UTC), systemd никогда не будет синхронизировать их обратно, так как это может смутить Windows при последующей загрузке.
  • systemd-analyze получил новую команду «verify» для оффлайн-валидации юнит-файлов.
  • systemd-networkd получил поддержку парочки дополнительных настроек для слития настроек сети. Также теперь можно настраивать метрику статично настроенных маршрутов. Для сетевых интерфейсов в случае необходимости можно настроить IP-адрес пира.
  • DHCP-сервер systemd-networkd больше не будет запрашивать вещание по умолчанию, так как это роняло некоторые сети. Для оборудования, где вещание необходимо, возможность можно включить обратно с помощью RequestBroadcast=yes.
  • systemd-networkd теперь задаёт адреса IPv4LL (если включено) даже если DHCP успешно настроен.
  • udev теперь по умолчанию отдаёт предпочтение именам сетевых устройств, предоставляемым ядром, если ядро указывает, что они предсказуемы. Это поведение можно изменить изменением NamePolicy= в соответствующем .link-файле.
  • Добавлена новая библиотека systemd-terminal, реализующая полную обработку и отображение TTY-потоков. Эту библиотеку планируется использовать в будущем для реализации подсистемы виртуальных терминалов целиком в пространстве пользователя, взамен текущей реализации в ядре.
  • Добавлен новый инструмент systemd-journald-upload для передачи данных журнала на удалённую систему с запущенным systemd-journal-remote.
  • journald больше не будет передавать все локальные данные другому запущенному syslog-демону. Это изменение сделано, поскольку rsyslog (являющийся на сегодняшний день наиболее широкоиспользуемой реализацией rsyslog) их больше не использует, и вместо этого вытягивает из журнала в свой собственный. Поскольку передача сообщений несуществующему syslog-серверу слишком затратна, было решено просто выключить её. Если у вас запущен syslog-сервер, отличный от последней версии rsyslog, эту опцию нужно снова включить (ForwardToSyslog= в journald.conf).
  • journald опционально поддерживает LZ4-компрессор для больших полей журнала. Этот компрессор работает намного лучше XZ, который использовался по умолчанию ранее.
  • machinectl теперь показывает IP-адреса локальных контейнеров, если знает их, плюс имя интерфейса контейнера.
  • Добавлен новый инструмент «systemd-escape», позволяющий легко экранировать строки для создания имён юнитов и т. п.
  • Сообщения sd_notify() теперь могут содержать новое поле ERRNO=, которое обрабатывается и сохраняется systemd, чтобы потом его можно было отобразить в выводе «systemctl status» для сервиса.
  • Добавлен новый компонент «systemd-firstboot», интерактивно запрашивающий для systemd наиболее базовую информацию (часовой пояс, имя хоста, пароль root) при первой загрузке. Ещё его можно использовать для предоставления этих вещей оффлайн в образах ФС, установленных в директории.
  • Сниппеты sysctl.d/ по умолчанию теперь выставляют net.ipv4.conf.default.promote_secondaries=1. Это позволяет не сбрасывать вторичные IP-адреса, когда первичные удалены.

>>> Источник

★☆

Проверено: fallout4all ()
Последнее исправление: JB (всего исправлений: 4)

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

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

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

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

А вообще-то оно 40 лет не зря работало. С другой стороны, те вещи, которые 40 лет не работали - никто не спешит заменять. Может это заговор против линукса - заменить все работающее, чтобы оставшиеся костыли никому не приглянулись?

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

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

Может это заговор против линукса

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

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

те вещи, которые 40 лет не работали - никто не спешит заменять

у тебя тв рубин и дисковый телевон? для тебя плохие новости

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

плохие новости

Прогрессивщики собираются поломать стандарты и пихнуть во все поля цифровое говно? знаем-знаем...

MiniRoboDancer ★☆
() автор топика
Ответ на: комментарий от segfault

Интересно, какова же у редхата целевая аудитория, если им на «ленивых» плевать?

Богатые дяди, экономящие на админах и готовые платить за поддержку от Шапки. Домашний юзер Шапке не нужен, ибо не будет платить.

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

Богатые дяди, экономящие на админах и готовые платить за поддержку от Шапки. Домашний юзер Шапке не нужен, ибо не будет платить.

Интересно, как поддержка от шапки может заменить админов? Они своих что ли командируют?

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

Например портируй любой IE под Linux чтоб оправдать свой бред. Или что нибудь другое, обосрешься без исходников моментально.

Т.е. если я дам тебе исходники ИЕ - то ты быстренько портируешь его на линукс?

условия работы линукса меняются - облака, виртуализация, объём обрабатываемых данных.

Отлично, вот только причем здесь Леннарт? На линуксе и без его поделок отлично крутятся облака «с виртуализацией и объемами данных».

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

Курсы RHCE/RHCA очень даже недешево стоят. К тому же оперативно диагностировать причину неполадок, связанных с работой сабжа, смогут только в фирме-производителе.

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

то ты быстренько портируешь его на линукс?

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

вот только причем

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

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

Курсы RHCE/RHCA очень даже недешево стоят.

При чем тут это?

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

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

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

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

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

sudo apt-get install wine


Не благодари.

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

Чем новая куча костылей лучше старой? В настройке она по-прежнему нуждается. А у хомячков и старое из коробки работало.

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

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

Не совсем так. Доходы не упали, но долю во многих областях они потеряли. Старистику по вэб серверам посмотри :)

А теперь... Ну нахрена завтра мне дебиан? Даже если привык - все привычки и старые наработки в утиль. Тогда я лучше в сторону центоси глядеть буду. Не зря же они ее пригрели ;)

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

портируешь
wine

Смищно.

Кстати, ты бы реально занялся, а то в вайне из коробки вместо осла какая-то жуткая пародия, ещё и на Gecko.

MiniRoboDancer ★☆
() автор топика
Ответ на: комментарий от segfault

Курсы RHCE/RHCA очень даже недешево стоят.

При чем тут это?

При том, что в сабже самому без поллитра не разобраться. Ситуация полностью аналогичная администрированию Windows Server. Без оконченых курсов Microsoft тебя никто и близко к серверной не подпустит.

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

в сабже самому без поллитра не разобраться

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

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

Давай, расскажи нам про эффекты действия всех возможных инструкций юнита.

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

Ты так говоришь, будто это что-то плохое ;-)

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

VT приходится всегда собирать. Там таких мест немало.

При включенном «Configure standart kernel features(expert users)»(название опции - CONFIG_EXPERT), VT можно выкомпилить, если тебе не нужны иксы на реальных терминалах и сами реальные терминалы. А вот если выпилишь TTY, то останешься и без SSH.

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

Если так получается, что API systemd затруднительно реализовать с помощью чистого POSIX — это проблема POSIX, во всех смыслах.

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

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

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

Например, если вместо ANSI С-совместимой frobnicate() используется какая-нибудь glibc-специфическая (или хуже) frobnicate2(), отличающаяся порядком параметров, — тогда да, бить по рукам нужно автора (т. к. не было никаких причин использовать нестандартный вариант).

Но в случае systemd использование ряда Linux-специфичных API, насколько понимаю, оправдано.

Взять fanotify(7) — первое, что пришло в голову. Позиция POSIX-пуристов выглядит так: «стандартным компонентам не нужно отслеживать изменения в файлах!один-один».

Или цгруппы. Отказываться от столь удобного инструмента управления иерархиями процессов в пользу бешеных танцев с /proc и нетлинком — ИМХО, глупо.

Особенно если учесть, что под вопросом стоит переносимость не на 50% систем, а на своего рода маргинальщину.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от Pinkbyte

Ну и да: у меня было написано

если API <...> затруднительно реализовать

Один вопрос — то, что сам по себе systemd Linux-специфичен. Может быть, это и проблема systemd (авторы настолько криворуки, что не умеют решать задачи средствами POSIX). Но и это вопрос спорный, см. мой пост выше.

Но вот если реализация API systemd в принципе невозможна средствами голого POSIX (т. е. невозможно написать вменяемую альтернативную реализацию) — то это уже точно проблемы POSIX.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от timuaz_one

А бредни «оно работало 40 лет пусть работает дальше» - на помойку

Колесо «работало» еще раньше. Так что, его на помойку? То, что доказало свою состоятельность должно оставаться.

Леннарт - зло. И не из-за его идей. Его идеи хороши. Его подход плох. Он сильно концентрирует всё на себя. Это как минимум вредно: как вредна монополия в сравнении со свободной конкуренцией. Но хуже всего - он создает единую точку отказа. Это очень опасно. Я периодически думаю, что он - спец. проект кого-то-там, созданный для уничтожения экосистемы Линукс.

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

Но вот если реализация API systemd в принципе невозможна средствами голого POSIX (т. е. невозможно написать вменяемую альтернативную реализацию) — то это уже точно проблемы POSIX.

А если реализация API, скажем, Windows невозможна средствами POSIX - это тоже проблема POSIX? Ты искривляешь логику.

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

Если найдено лучшее решение надо его применять, а не прикриваться лозунгами «работало же кучу лет, зачем что-то менять?»

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

Его подход плох. Он сильно концентрирует всё на себя. Это как минимум вредно: как вредна монополия в сравнении со свободной конкуренцией.

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

Тоесть ты лицемерно обсираешь Леннарта и не трогаешь Линуса который делает тоже самое. Тебе не кажется это несправедливым?

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

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

Нет, я просто опускаю одну из предпосылок («systemd API нужно с т. з. тех, кто заявляет о проблеме невозможности такой реализации») как очевидно верную.

Невозможность написания POSIX-чистого libwine действительно является проблемой той группы лиц, которая изъявляет желание запускать Win32-программы под POSIX-чистой ОС.

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

!многопоточность нужна || POSIX-штрих говно
, т. е.
многопоточность нужна -> POSIX-штрих говно
(с точки зрения конкретно взятого девелопера).

Ты ведь лично согласен с тем, что если бы в POSIX не было многопоточности, твои (многопоточные) программы пришлось бы делать не-POSIX-чистыми, а не брезгливо выкидывать многопоточность как явление?

У нас же есть многочисленные подтверждения того, что многие из API systemd действительно нужны: ну, просто их начинают использовать. (И вот только не нужно тут говорить про subtle arts of murder and persuasion и про то, что Поттеринг ночью с 12GA пришёл к Грасслину и заставил его заюзать logind API.)

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

чуваки с подкаста залили мне весь монитор спермой на тему Лёни - http://mezhdunarodnye.rpod.ru/330603.html

эх, линукс уже не торт, корпоратсты рулят под себя.

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

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

Гонка комбайнов? Это как сейчас в WebKit тянут кучу HTML5 говна, лишь бы заставить других догонять? А вообще, Спольски давно ответил на эту тему Огонь и движение

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

гонка продуктов одного класса. потому что конкуренция systemd и sysv напоминает бугатти и ладу. а апстарт в последние пару лет нифига нового не сделал, только копипастил - какая тут может быть конкуренция? смех да и только.

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

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

А вообще, Спольски давно ответил на эту тему Огонь и движение

я еще не настолько деградировал чтобы читать откровения сотрудников Microsoft.

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

на винфаке найдутся куда более благодарные читатели этого дерьма.

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

Линуса нафиг, из-за его прыщеподелия гня скатилась.

MiniRoboDancer ★☆
() автор топика
Ответ на: комментарий от timuaz_one

Если найдено лучшее решение надо его применять, а не прикриваться лозунгами «работало же кучу лет, зачем что-то менять?»

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

Тоесть ты лицемерно обсираешь Леннарта и не трогаешь Линуса который делает тоже самое. Тебе не кажется это несправедливым?

А ну покажи где я обсираю Леннарта?! Вот за что я еще не люблю systemd, так это за то, что с его преверженцами очень редко получается говорить нормально, аргументированно: как правило разовариваешь с ихними тараканами в голове и детским максимализмом.

И, да, кейс с ядром не аналогичен.

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

Ты ведь лично согласен с тем, что если бы в POSIX не было многопоточности, твои (многопоточные) программы пришлось бы делать не-POSIX-чистыми, а не брезгливо выкидывать многопоточность как явление?

Хороший пример. Хороший прием - использовать в примере чт-то очевидное. Теперь давай заменим «многопоточность» на «рисовать на экране зеленых человечков» и еще раз перечитаем текст. Получится еще один хороший пример. Как считаешь, отсутствие в POSIX средств рисования зеленых человечков - является это проблемой POSIX? Очевидно что нет, ибо эта функция понадобилась одной программе/девелоперу.

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

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

Хотя, опять же, у меня претензия не к его идеям, а к подходу.

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

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

И вот у нас есть программа, которая хочет это делать. Она будет это делать не через POSIX. Ты говоришь, что это не проблема POSIX, потому что фича потребовалась лишь «одному девелоперу». Но если эта программа становится широко используемой... то рисование зелёных человечков становится «нужно» не только автору программы, но и её пользователям. Согласен?

Нужность транзитивна. А поскольку нужность API systemd мы тут вроде как считаем истиной (см. выше — со слов разработчиков вроде Грасслина, ну и вообще, «если API используют, значит, он нужен»), то

Или пусть тогда Леннарт покажет/докажет сообществу, что это и правда нужно/полезно; кто знает, может и правду новатор.

...уже происходит.

Как-то так.

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

а попробуй-ка собери SLiM с работающим без systemd-logind slimlock, а я на тебя погляжу ;)
Эта взаимозаменяемость - лажа чистой воды.

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

Но если эта программа становится широко используемой... то рисование зелёных человечков становится «нужно» не только автору программы, но и её пользователям. Согласен?

Не согласен. Пользователям абсолютно все равно что там внутри, и какое API используется. Так что считаем только разработчиков: один.

А поскольку нужность API systemd мы тут вроде как считаем истиной (см. выше — со слов разработчиков вроде Грасслина, ну и вообще, «если API используют, значит, он нужен»)...

Не считаем.

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

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

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

Еще раз очерчу свою позицию: я не считаю systemd лучше или хуже (хоть и откровенно не поддерживаю некоторые нововведения). Но я считаю, что финальный выбор должен сделать пользователь. Голосовать нужно рублем установками. А для этого 1) у пользователя должен быть выбор; 2) по возможности исключить «промывку мозгов». Вот с этими двумя пунктами у systemd проблемы, и вот против этого я и выступаю. То есть проблема в подходе. А вопросы API в ядре - будем и решать после понимания нужности systemd в соответствии с критериями выше.

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

Не согласен. Пользователям абсолютно все равно что там внутри, и какое API используется. Так что считаем только разработчиков: один.

так что ж ты не на венде? тебе же всё равно!

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