LINUX.ORG.RU
ФорумTalks

Systemd - от системы инициализации к набору блоков для построения ОС

 


0

0

Леннарт Поттеринг (Lennart Poettering) представил свою речь [слайды в PDF), прозвучавшую на конференции FUDCON Beijing 2014 и посвящённую настоящему и будущему системы инициализации systemd. В выступлении поясняется изменение фокуса развития проекта от системы инициализации к набору базовых компонентов для построения операционных систем. По мнению Поттеринга, такой подход снизит уровень различия между дистрибутивами Linux и за счёт унификации компонентов в дистрибутивах повысит конкурентоспособность Linux как операционной системы общего назначения. Из планов на будущее отмечается реализация локального кэша DNS, создание простого сервера (Multicast DNS) и LLMNR (Link Local Multicast Name Resolution), добавление во встроенный резолвер системы для верификации DNSSEC, продвижение Kdbus в состав ядра Linux, улучшение интеграции с системами контейнерной изоляции.
Сперто с опеннета.

★★★

Последнее исправление: Andrew (всего исправлений: 2)

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

%)

Если кто-то хочет запустить линуксовую систему инициализации вовне линукса, то это их проблемы, не? :)

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

Ровно до тех пор, пока она остается линуксовой системой инициализации, а не

набору базовых компонентов для построения операционных систем

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

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

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

Рано или поздно в этом мире только одна вещь случается %)

Deleted
()

А вот теперь и правда пора валить. Как там дела в слаке?

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

Парень создал себе идеальную работу.

Думаю, на системд всё не закончится. Потом создадут другую систему, такую же как системд, но лишенную её недостатков. В этом весь линукс-долгострой ради долгостроя.

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

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

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

Может плохо смотришь? Я после journalctl испытываю дискомфорт, когда приходится изучать логи в системах без systemd.

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

Приготовился загибать пальцы, жду примеров.

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

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

Думаю, на системд всё не закончится

«Думаешь»? Это прямо сказано: «never finished, never complete».

В этом весь линукс-долгострой ради долгостроя.

Линукс здесь не причем. Корпорасты и вендовые птушники просто нашли друг друга.

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

а с journald у меня есть такой выбор?

journald может дублировать вывод в текстовом виде

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

Ты сидишь на самописном браузере под самописным ДЕ в самописных иксах поверх самописного ядра? Или всё же жрёшь те драйвера, которые тебе даёт Линус и пользуешься тем браузером, который тебе дают его разработчики?

я буду документацию по journalctl буду дольше читать, чем напишу однострочник на перле

Нежелание читать документацию — сильный аргумент против продукта. Как ты вообще умудрился с таким подходом придти к линуксу не очень понятно — читать документацию тут надо много где. При этом документацию прочитать надо один раз, а однострочники писать каждый раз, когда что-то в логах надо. Не говоря уж о том, что человек, способных прочитать man journalctl в мире на порядки больше, чем знатоков перловых однострочников. Ну и в качестве домашнего задания напиши однострочник, реализующий journalctl -b -1 -p err -u some.service (вывести все сообщения определённого сервиса с уровня error и важнее за прошлую загрузку)

меньше гибкости

Упрлс? Как может быть меньше гибкости у инструмента, способного имитировать предыдущее поведение?

хрен выпилишь

А недостатком КДЕ можно считать, что из него Qt не выпилить? А недостатком человека, что руки не отстёгиваются? Нравится или нет, но это — часть systemd.

замена годами обкатанных компонентов

Предлагаешь выпилить все эти syslog, rsyslog, syslog-ng, ведь раньше и без них годами работало? И линукс заодно выкинуть, GNU и на миниксе работало.

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

GNU и на миниксе работало.

Был бы 32-битный свободный Minix - не было бы Linux.

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

Ты сидишь на самописном браузере под самописным ДЕ в самописных иксах поверх самописного ядра? Или всё же жрёшь те драйвера, которые тебе даёт Линус и пользуешься тем браузером, который тебе дают его разработчики?

я могу их менять, в зависимости от потребностей и настроения. но скоро будет ситуация, что выпилить systemd из GNU/Linux будет весьма проблематично. совсем не так, как поменять браузер или DE. и это печалит.

Как ты вообще умудрился с таким подходом придти к линуксу не очень понятно — читать документацию тут надо много где.

подход следующий: документация читается в рамках реализации конкретной задачи. и да - я не говорил, что читать мне ее не нравится.

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

как я и писал выше - ориентированность на идиотов. это печально, не?

Предлагаешь выпилить все эти syslog, rsyslog, syslog-ng, ведь раньше и без них годами работало? И линукс заодно выкинуть, GNU и на миниксе работало.

предлагаю не прибивать все это гвоздями. мне еще ни разу не встречалась задача (в контексте инициализации и логгирования), не решаемая с помощью sysVinit/rsyslog/скриптов. да, я за 10 с лишним лет пользования GNU/Linux привык к этим инструментам. что в этом плохого?

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

О.к.
Очень клево, что есть linlap wiki и хотя бы список поддерживаемых wifi-карточек в каждом драйвере, облегчает поиск :)
Хотя в ближайшее время и не собираюсь покупать под опенок еще какой-нибудь девайс.

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

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

Отнюдь. Скорее, признак идиота — это забивание гвоздей микроскопом и нерациональная трата времени.

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

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

Аа, речь про это...

Ну пусть пилит. Годное дело делает. Всё равно потом все привыкнут и успокоятся :)

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

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

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

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

Впрочем, что я объясняю. Если ты субъективно считаешь, что тебе он не нужен — твоё право. Но субъективное.

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

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

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

Назови хоть одну причину, почему одно ядро - это хорошо, а один системд - плохо.

Linux kernel системообразующий компонент — основа операционной системы. (ещё могу предположить, что X.org являются такой технологией. Почти, только в другой «сфере») А система инициализации, или то, во что вылилось теперь SystemD, очевидно таковым (основой ОС) не является, и должно быть заменимо. (дальше можно развить мысль о том почему его придётся заменять полностью, о принципах и традициях архитектуры компонентов GNU/Linux, и чем SystemDот них отлична, духе FOSS и о том, почему сообщество противится таким идеям.

И ещё добавлю: X.org имеет двух «сыновей» — Wayland и Mir.

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

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

«Вы можете приобрести у нас автомобиль любого цвета, при условии, что он будет чёрным»©

Gotf ★★★
()

Ничему не удивляюсь. Поттеринг решил закопать Avahi который сам написал?

vertexua ★★★★★
()
8 октября 2014 г.
Ответ на: комментарий от redgremlin

Собственно у меня отключена запись лога в журналд, и настроено на форвард в syslog-ng, т.к. бинари как логи - злющее зло, бывали ситуации, когда необходимо прочитать что же случилось с системой и из утилит cat/less/more, удачи читать бинарники.

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

бывали ситуации, когда необходимо прочитать что же случилось с системой и из утилит cat/less/more

Пошёл на рыбалку, а удочку не взял? Если я пользуюсь journald, то у меня, разумеется, доступность journalctl, на случай внезапной поломки, обеспечена. И если в твоих тестовых логах у тебя с полмиллиона строчек, то less поможет никак и тебе захочется как минимум grep, а ещё лучше perl или awk, что ничем не отличается от требования наличия journalctl в случае бинарных логов.

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

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

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