LINUX.ORG.RU

uselessd — форк systemd

 , ,


6

8

uselessd — попытка урезать systemd до базовых функций: initd, супервайзор процессов, система зависимостей — но без изоляционизма и агрессивной навязчивости (когда комбайн лезет всюду и делает себя незаменимым). Также обеспечивается поддержка платформ без glibc и планируется поддержка ядер отличных от Linux. За основу взят systemd 208.

На сайте перечислены следующие ключевые отличия:

  • Совместимость с musl и uClibc.
  • Отказ от journald, libqrencode и libmicrohttpd. Отказ от бинарных логов. Лог по умолчанию идёт в LOG_TARGET_KMSG_OR_SYSLOG.
  • libudev и udevd необязательны. Ноды устройств можно создавать чем угодно.
  • Удалены избыточные типы юнитов: devices, timers, swaps, mounts, automounts.
    • Device units завязаны на udev и вместо них можно обойтись правилами udev.
    • Timer units не нужны, так как есть cron и его новые аналоги, например fcron.
    • Swap units удалили как сложные, агрессивные и малополезные. Рекомендуют пользоваться настройками sysctl и util-linux.
    • Automount units и mount units удалены для упрощения. Рекомендуют autofs или Berkeley Automounter.
  • Удалены вспомогательные демоны (hostnamed, timedated, localed, logind...) Удалены генераторы кроме getty-generator и rc-local-generator, так как они дублировали имеющийся функционал или были привязаны к удалённым типам юнитов.
  • Удалены средства настройки систем MAC/ACL, включая SMACK, IMA и SELinux, чтобы не загромождать и не привязываться к одной системе. Для совместимости с существующими конфигурациями остались поддержка SELinux в D-Bus API и SMACK в сокетах.
  • systemd-fsck заменили вызовом /sbin/fsck.
  • Частичная поддержка FreeBSD.

Авторы uselessd подчёркивают, что он ещё сырой, и не рекомендуют его для повседневного использования.

Новость на OpenNet

Исходные тексты

>>> Сайт проекта

★★★★★

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

урезать
Отказ от
Отказ от
Удалены
не нужны
удалили как сложные
удалены для упрощения
Удалены
Удалены
Удалены
заменили

А что осталось то?

kernelpanic ★★★★★
()

Нужно, годно.

Подписался на новый тег. Ждем историй успеха

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

может выше/ниже ответили, но anacron.

то есть я правильно понимаю что anacron запустит задачу сразу после включения компьютера в случае если прошлый запуск задачи уже «просрочился»?

если ответ «да», то в этом случае возникается следующий вопрос:

что именно такое это "сразу после включения"? в каком смысле "сразу"?

1. например если это "сразу" — оказывается слишком рано (прям СРАЗУ после включения компьютера и запуска демона anacron) — то быть может система ещё не готова, система ещё не успела запустить все необходимые служебные демоны для того чтобы наша задача смогла успешно выполниться. слишком рано, да..

2. а если например это "сразу" — означает минут через 5 после включения компьютера (через 5 минут после запуска демона anacron) — то быть может это уже слишком поздно и компьютер окажется к тому времени опять выключенным. слишком поздно, да..

------------------------------------------------------------

а вот systemd-timers — делается с учётом зависимости запускаемой задачи от других юнитов. так что эта проблема решается на фундаментальном уровне systemd.. «просроченная» задача запускается рано, не не слишком рано :)

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

1) придумываем маргинальный случай, когда systemd лучше;
2) с боевым видом спрашиваем у всех «а что тогда? а что тогда?»
3) никто ничего не ответит
4) ???
5) доказано: системд лучше всех!

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

а вот systemd-timers — делается с учётом зависимости запускаемой задачи от других юнитов.

Нет, systemd-timers делается только из-за тотального незнания матчасти. Сложный шедулинг все равно останется в приложении, а приколоченный крон-переросток просто ненужен.

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

ну тогда я опишу и ваш случай..

1. если некая общая проблема..
2. придумываем кривой способ, который решает эту проблему в 90% случаев..
3. радумемся что мы случайно не оказались в других 10% случаях..
4. ???
5. с гордостью произносим — "у меня всё работает, а у те у кого вдруг возникли на ровном месте глюки — те сами дураки!"

:-D

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

3 дня назад.

Ты эти коммиты смотрел? Мерджинг из udev'а, правка своей отсебятины для успешности мерджа, ну и удалили пару пустых строк.

Я тебя спрашиваю про связь между kdbus и udev?

we already made clear that soon after kdbus is merged into the kernel we'll probably make a hard requirement on it from the systemd side.

Also note that at that point we intend to move udev onto kdbus as transport, and get rid of the userspace-to-userspace netlink-based tranport udev used so far.

redgremlin ★★★★★
()

Не дотерпели до 1 апреля :(

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

придумываем маргинальный случай, когда systemd лучше; [...] доказано: системд лучше всех!

на самом деле — то что я выше написал — это просто я указал на связь того почему на мой взгляд компонент «systemd-timers» является неотъемлемой частью системы инициализации.

а если это всё-таки реализовать отдельно (как оно было раньше в sysvinit) — то получается [более ненадёжно и более криво]. :)

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

Если они предложат адекватную замену, то ок, но пока не видел.

Насколько я понял, пока её нет.

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

Если коту отрезать лапы, хвост и яйцы, это конечно все еще будет кот, но какой-то неправильный и неполноценный кот.

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

Ммм, по fstab'у генерируются точно такие же mount-юниты (см. systemd-fstab-generator); авторы systemd и то рекомендуют юзать fstab.

Это потому что формат может быть не окончательный. Мне это не грозит, у меня нет роллинга в продакшене. А systemd меняется достаточно быстро, так что при апдейте дистров всё равно придётся читать доки, что поменялось.

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

Скорее кот в ластах, с рогом и в раковине отбросил ненужное.

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

Сложный шедулинг все равно останется в приложении, а приколоченный крон-переросток просто ненужен.

согласен(!), в том смысле что если бы logrotate (и другие подобные утилиты) был бы реализован как демон который постоянно весит в памяти (а не запускается каждый раз кратковременно по таймеру\крону) — то так было бы лучше.

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

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

а засвети содерживое этих своих файлов..

Там фактически просто скопированы сгенерированные юниты, отличия косметические, только у сетевых каталогов поправлены TimeoutSec и добавлено OnFailure.

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

Насколько я понял, пока её нет.

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

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

we already made clear that soon after kdbus is merged into the kernel we'll probably make a hard requirement on it from the systemd side.

Also note that at that point we intend to move udev onto kdbus as transport, and get rid of the userspace-to-userspace netlink-based tranport udev used so far.

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

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

we already made clear that soon after kdbus is merged into the kernel we'll probably make a hard requirement on it from the systemd side.

Also note that at that point we intend to move udev onto kdbus as transport, and get rid of the userspace-to-userspace netlink-based tranport udev used so far.

Какие проблемы использовать kdbus в форке?

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

kdbus требует некоторой юзерспейсной части (маршаллер, там, проверки прав доступа), которую на данный момент реализовали только в systemd.

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

Кто вообще ввел в моду ставить союз «но» предложениях, в которых следует ставить «а»?

Семантика противопоставления у «но» была с незапамятных времен.

bj
()

То, что форкают systemd, уже говорит о том, что он становится мейнстримом.

Infra_HDC ★★★★★
()

uselessd — попытка урезать systemd до базовых функций: initd, супервайзор процессов, система зависимостей

Годновато! А нормальные юнит-файлы будут?

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

компонент «systemd-timers» является неотъемлемой частью системы инициализации.

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

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

Я тебя спрашиваю про связь между kdbus и udev?

Он думает, что кроме поцтеринга никто больше не умеет писать код.

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

да! да! всё верно! :)

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

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

компонент «systemd-timers» является неотъемлемой частью системы инициализации.

Кофеварку, кофеварку и макбук забыли! какой-же инит без них?

devl547 ★★★★★
()

Если разработчики uselessd более-менее адекватные люди, то они должны понимать, что у их проекта шансы на выживание очень невысоки. Что касается самого systemd — оно до сих пор сырое, жирное и упоротое и почему-то живое до сих пор.

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

БедОС-3 «Таня»

Аналогия была бы уместна, если бы systemd распространялся под закрытой лицензией.

А так - нормальный проект. Вдруг взлетит...

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

Если разработчики uselessd более-менее адекватные люди, то они должны понимать, что у их проекта шансы на выживание очень невысоки. Что касается самого systemd — оно до сих пор сырое, жирное и упоротое и почему-то живое до сих пор.

думаю что uselessd — это отличный проект, который:

1. [высокая вероятность ожидания]: либо — показательно докажет сообществу факт того что systemd не такой уж и нагромаждённый (факт того что все компоненты systemd — являются неотъемлемой частью хорошо-работающей системы инициализации).

2. [низкая вероятность ожидания]: либо — показательно докажет сообществу факт того что systemd якобы действительно слишком нагромождённый и что всё-это можно было бы многократно упростить.

user_id_68054 ★★★★★
()

WE ARE THE CHAMPIONS, MY FRIEND!

Наконец-то это случилось! ГовноД теперь умрет, и никому не будет до этого дела! Десять шикарных девственниц каждому из разработчиков этого проекта!

anonymous
()

нужно.

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

> Justice will prevail

Это то, о чём я думаю?

нет, это не оно.. просто я люблю справедливость :-D

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

«Необходимые права на устройства» раздают chgrp и usermod.

Они раздают больше, чем необходимо.

Это, извините, как? Вы пользователей в группы пихаете левой пяткой по принципу «а чтобы вдруг» и «на всякий случай», что ли?

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

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

Ivan_qrt правильно сказал — «впрочем, для однопользовательского локалхоста этого достаточно». Это и объясняет, почему пол-ЛОРа хейтит logind и транзитивно systemd: они просто никогда не слышали о таких юзкейсах.

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

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

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

...но только получится что отличий от root — не сильно много :)

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

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

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

Только после этого в нашем скромном мирке останется полтора «нормальных» анонимуса во главе с тобой. Мне кажется такое явление даже имеет название ;)

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

Нужно больше систем инициализации.

Ты наверное и не представляешь, насколько ты прав

KennyMinigun ★★★★★
()

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

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

Я уже здесь, по тегу скастовался. Чем могу помочь? :3
intelfx ★★ (21.09.2014 22:01:05) systemd-обожающий. Никто никого так не полюбит!

блин, ты же сменил аватарку
я тебя не узнал! :)

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

Зачем, если эти же mount-юниты генерируются на лету из того же fstab, и на них можно ровно так же вешать зависимости?

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

Слышать недостаточно. Носиться со словом multiseat, как с писаной торбой, все умеют, а какие проблемы при этом решаются этими logind и прочими *kit-ами, почему простых групп не хватает, и зачем всем внезапно понадобилось различать локальных и удалённых пользователей, так никто объяснить и не может.

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