systemd 246

Вы имеете в виду управление cgroups? – Оно осуществляется через юниты типов scope и slice

Да, спасибо, уже сам нашёл. Как и то, что разных типов юнитов там больше десятка, и сколько, под этим соусом, можно в пид1 разных «менеджеров» впихнуть, теперь уже так просто не узнать. Наверное, не стоит уже и пытаться.

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

На выходных будет виртуальная Fedora-конфа. Там Facebook будет рассказывать про применения Fedora и CentOS на «боевых» серверах.

Так вот они используют специальную кастомную сборку с самым новым ядром и systemd потому что не могут ждать пока обновки докатятся даже до Fedora, им нужны все те фичи, что systemd выкатывает. И никакой стабильности им не нужно, потому что у них есть CI, и blue-green deployment.

вместо новых методов, смотрят по имени юнита, имеет ли он вид *.slice, или не имеет?

Что такое «вместо новых методов смотрят по имени юнита»?

И, в зависимости от этого, работают с этими юнитами не так, как с обычными?

Что такое «обычные юниты» и «необычные юниты»?

Иди и почитай, как вообще работает объект обсуждения. Заодно почитай про ООП.

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

Там ровным счётом ничего сложного. man systemd:

       The following unit types are available:

        1. Service units, which start and control daemons and the processes
           they consist of. For details, see systemd.service(5).

        2. Socket units, which encapsulate local IPC or network sockets in the
           system, useful for socket-based activation. For details about
           socket units, see systemd.socket(5), for details on socket-based
           activation and other forms of activation, see daemon(7).

        3. Target units are useful to group units, or provide well-known
           synchronization points during boot-up, see systemd.target(5).

        4. Device units expose kernel devices in systemd and may be used to
           implement device-based activation. For details, see
           systemd.device(5).

        5. Mount units control mount points in the file system, for details
           see systemd.mount(5).

        6. Automount units provide automount capabilities, for on-demand
           mounting of file systems as well as parallelized boot-up. See
           systemd.automount(5).

        7. Timer units are useful for triggering activation of other units
           based on timers. You may find details in systemd.timer(5).

        8. Swap units are very similar to mount units and encapsulate memory
           swap partitions or files of the operating system. They are
           described in systemd.swap(5).

        9. Path units may be used to activate other services when file system
           objects change or are modified. See systemd.path(5).

       10. Slice units may be used to group units which manage system
           processes (such as service and scope units) in a hierarchical tree
           for resource management purposes. See systemd.slice(5).

       11. Scope units are similar to service units, but manage foreign
           processes instead of starting them as well. See systemd.scope(5).

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

Я понимаю, что количество новой информации сперва кажется несколько подавляющим. :) Однако, как только удаётся понять основные концепции, всё тут же выстраивается в довольно стройную, логичную и понятную картину.

Вы, простите, откуда, коллега? Страна, город?

Я понимаю, что количество новой информации сперва кажется несколько подавляющим. :)

Да не в этом дело. Ну вот когда ещё можно было разным процессам сигруппы менеджерить, то логинд отлично жил отдельно. И никаких slice и scope юнитов не было, так? Потом его запихали в пид1, и они появились, так? А теперь вы об этом всём говорите так, будто только так, как сейчас, и может быть. Но ведь было по-другому: разных типов юнитов было меньше, и логинд отлично жил отдельно.

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

Ну вот когда ещё можно было разным процессам сигруппы менеджерить, то логинд отлично жил отдельно. И никаких slice и scope юнитов не было, так? Потом его запихали в пид1, и они появились, так?

Кого «его» запихали в systemd? logind? – ну тогда это неправда.

systemd и ранее «рулил» своими cgroups – так что с помощью scope и slice просто вынесли эту уже имевшуюся функциональность во внешний интерфейс, позволив использовать её из других программ.

Почитайте в начале приведённого ранее документа – там и предыстория, и аргументация текущей архитектуры даны достаточно подробно.

Но ведь было по-другому: разных типов юнитов было меньше, и логинд отлично жил отдельно.

Он и сейчас живёт отдельно от PID 1 – в смысле отдельным процессом. Вся логика управления сеансами осталась в нём, и лишь управление cgroups «перешло» в systemd init (в кавычках, поскольку оно там уже было изначально).

Вопрос: как же нам теперь узнать, сколько ещё, из имеющегося «зоопарка» юнитов, можно было бы точно так же заменить некоторым отдельным менеджером?

Так эти юниты появились ровно потому, что стало невозможно их «заменить некоторым отдельным менеджером»! Это путь в обратном относительно приводимого вами направлении.

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

Это какие-то пространные рассуждения, если честно. «Мы видим, как человек съел помидор – так кто теперь скажет, что обратное невозможно?»

Вот есть список типов юнитов – какие именно вы хотели бы выделить в отдельный процесс, и чего этим хотите добиться?

Кого «его» запихали в systemd? logind? – ну тогда это неправда.

Ну, не весь…

Вот есть список типов юнитов – какие именно вы хотели бы выделить в отдельный процесс, и чего этим хотите добиться?

Нет, вообще никакие. Мы изначально хотели узнать, какие из имеющихся сервисов, кроме логинда и уже указанных нескольких других, лазят к пид1. Ради этого я и хотел «просто глянуть АПИ». Но теперь выяснилось, что там для них могут быть просто «свои типы юнитов», и по АПИ мы мало что увидим.

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

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

У тебя какое-то странное представление про API. По нему нельзя узнать кто пользуется, по нему можно только узнать какие данные предоставляются, а пользоваться может кто угодно.

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

Я ожидал, что в АПИ явно увижу управление сигруппами. Не увидел. Оно там ну прям очень уж «неявно». Значит, этим путём пройти не удалось, но в целом-то, почему представления странные? Думал, методы новые добавили, а добавили новые типы юнитов.

Я ожидал, что в АПИ явно увижу управление сигруппами.

Это что тебя натолкнуло на подобную идею?

Это что тебя натолкнуло на подобную идею?

Тот факт, что в пид1 перенесли управление сигруппами в какой-то момент. Ожидал, что это «оставит след» в его АПИ. Точнее, оно уже и так там было, просто логинд стал им пользоваться. Вот по тому и ожидал.

в пид1 перенесли управление сигруппами в какой-то момент

Откуда перенесли? В какой момент?

это «оставит след» в его АПИ

Чего? Что вообще такое по-твоему «АПИ»?

Точнее, оно уже и так там было

Перенесли то, что уже там было? Ты под газом что-ли?

Откуда перенесли? В какой момент?

Да ни в какой, оно и так там уже было. Просто увидеть в АПИ его ожидал.

Чего? Что вообще такое по-твоему «АПИ»?

https://www.freedesktop.org/wiki/Software/systemd/dbus/ Вот АПИ системд-пид1. Сами посмотрите.

Да ни в какой, оно и так там уже было.

Хмм. Вроде бы до пятницы далеко ещё.

Просто увидеть в АПИ его ожидал.

Давай попробуем ещё раз - почему ты его ожидал там увидеть?

Давай попробуем ещё раз - почему ты его ожидал там увидеть?

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

системд-пид1 имеет средства управления сигруппами, и они доступны другим сервисам через дбас

Ты ожидал увидеть в дбас апи управления сигруппами потому что в дбас есть апи управления сигруппами. Правда его там на самом деле нет. Мда… Что ты такое принял?!

Ты ожидал увидеть в дбас апи управления сигруппами потому что в дбас есть апи управления сигруппами. Правда его там на самом деле нет.

В виде соответствующих методов, его там не оказалось. Реализовали его не новыми методами, а новыми типами юнитов.

Мы изначально хотели узнать, какие из имеющихся сервисов, кроме логинда и уже указанных нескольких других, лазят к пид1

Это не имеет отношения к модульности/монолитности.

Вы, вероятно, хотели сказать, что желали бы проверить, что отдельные компоненты systemd действительно реализуют свои функции, а не являются тонкими прослойками, в то время как вся функциональность на самом деле - в PID 1. Верно?

Но теперь выяснилось, что там для них могут быть просто «свои типы юнитов», и по АПИ мы мало что увидим.

Почему? Вы знаете API, вы знаете существующие типы юнитов – этого достаточно для понимания того, какие именно задачи выполняет PID 1.

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

Ну получите вы список – дальше что? Важен же не сам булевый факт обращения к PID 1, а то, зачем это делается.

Вы ведь хотели понять, не перегружен ли PID 1, – как такой список поможет вам в этом?

В виде соответствующих методов

Эм… а как ты вообще себе API представляешь?

его там не оказалось.

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

Реализовали его не новыми методами, а новыми типами юнитов.

Чё? Это как?

Вы, вероятно, хотели сказать, что желали бы проверить, что отдельные компоненты systemd действительно реализуют свои функции, а не являются тонкими прослойками, в то время как вся функциональность на самом деле - в PID 1. Верно?

Ну… скорее, нет. Лазят/нет - это сразу же скажет о том, насколько легко/сложно пид1 заменить. И если окажется, что никто больше не лазит, то, значит, заменить его не сложнее, чем поставить елогинд. Чего ещё желать. Правда, если окажется, что все лазят - придётся уже разбираться по другим критериям, что вы и предлагаете делать сразу. Но ведь и других критериев пока тоже нет, так хоть так бы проверили.

Почему? Вы знаете API, вы знаете существующие типы юнитов – этого достаточно для понимания того, какие именно задачи выполняет PID 1.

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

Ну получите вы список – дальше что? Важен же не сам булевый факт обращения к PID 1, а то, зачем это делается.

А если окажется, что список пустой, или небольшой? Это уже будет результат.

Вы ведь хотели понять, не перегружен ли PID 1, – как такой список поможет вам в этом?

Вы хотите другой критерий предложить? :) Я не против, ведь пока у нас совсем ничего нет.

Заканчивайте спорить о бессмысленной фигне. Больше 10 комментов уже наспорили.

Да мы и не спорим даже уже. А пытаемся понять, как бы количественно оценить то, о чём хотим поспорить. :)

Ты это написал в треде про systemd, серьезно?

Этим дискуссиям на днях десятый год будет, а ты только 10 комментов насчитал.

Этим дискуссиям на днях десятый год будет, а ты только 10 комментов насчитал.

Может, кто-то их подытожил в какой-нибудь статейке?

Может, кто-то их подытожил в какой-нибудь статейке?

http://0pointer.de/blog/projects/the-biggest-myths.html

Про внутренности пид1, его связку с логиндом и другими сервисами - там ничего. И в самом начале ещё приводят, в качестве примера, 3 сервиса, которые можно использовать без системд. Вот нет бы весь список привести! :) Будто специально обходили самые интересные вопросы стороной.

Я готов считать, что пид1 не перегружен, если не найду признаков того, что к нему кто-то лишний лазит.

Странные у вас понятия. Если кто-то лишний лазит, хотя не должен, – это ведь вина этого лишнего, а не PID 1, не так ли?

Вне зависимости от того, можно ли, в теории, вынести из него что-то ещё, или нет.

А вот это как раз хороший критерий.

«PID 1 перегружен» означает «в PID 1 присутствует функциональность, которой там совсем не место». Соответственно, если такой явно лишней функциональности в нём нет, то его нельзя назвать перегруженным.

(Я, кстати, гораздо чаще встречаю заявления о том, что systemd как проект перегружен, – и небезосновательные – а про PID 1 споры вроде бы давно утихли.)

А если окажется, что список пустой, или небольшой? Это уже будет результат.

Ну допустим, что список небольшой. Это может означать как то, что функциональность PID 1 невелика, и остальные сервисы самостоятельно выполняют основную часть своей работы, – так и то, что PID 1, наоборот, «вещь в себе»: делает всё сам, и поэтому к нему нет нужды часто обращаться извне.

Количество клиентов само по себе ещё ничего не говорит о сути выполняемой сервером работы.

Странные у вас понятия. Если кто-то лишний лазит, хотя не должен, – это ведь вина этого лишнего, а не PID 1, не так ли?

Нет, ведь раз лазит, значит, есть для него там АПИ. Это ведь взаимосвязанные вещи.

А вот это как раз хороший критерий.

А только не проверяемый. При большом желании, можно откуда угодно всё повыносить. Но это уже будет редизайн. Мы ведь не обсуждаем, можно ли как-то по-лучше системд задизайнить, так как всё в мире можно улучшить. Вопрос у нас вполне конкретный: кто-то умышленно делал ли так, чтобы системд-пид1 всегда возвращался по зависимостям, или нет. Если окажется, что кто-то туда необоснованно лазит (и там есть ему АПИ), то это будет указанием на такую вот вещь. Ну и, заодно, на то, что пид1 лишний функционал содержит.

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

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

а про PID 1 споры вроде бы давно утихли.)

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

так и то, что PID 1, наоборот, «вещь в себе»: делает всё сам, и поэтому к нему нет нужды часто обращаться извне.

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

кто-то туда необоснованно лазит

Что и кому по-твоему нужно обосновывать?

то это будет указанием на такую вот вещь

На какую вот вещь? Ты сам-то пробовал читать то, что ты пишешь?

насколько его «незаменяемость» оправдана

Оправдана перед кем? Ты точно всё ещё про программы рассуждаешь?

Ну так выложи свою версию инит скрипта

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

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/migration_planning_guide/sect-networking-upstart

In Red Hat Enterprise Linux 6, init from the sysvinit package has been replaced with Upstart, an event-based init system. This system handles the starting of tasks and services during boot, stopping them during shutdown and supervising them while the system is running. For more information on Upstart itself, refer to the init(8) man page.

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

В убунте он, кстати, точно так же не работает ни рожна.

Ты, как и я, познал страсть в избытке.

Я готов считать, что пид1 не перегружен, если не найду признаков того, что к нему кто-то лишний лазит.

Это очень странный критерий перегруженности. Ему (systemd) специально сделали публичный API, чтобы любое ПО при необходимости могло к нему обращаться для целей управления системой. Совсем как у ALSA/PulseAudio для захвата и вывода звука или, скажем, X.Org для вывода графиги и захвата ввода. Становится ли что-то автоматически перегруженным из-за предоставления возможности стороннему ПО работать с ним? Думаю, что нет.

Может, кто-то их подытожил в какой-нибудь статейке?

http://0pointer.de/blog/projects/the-biggest-myths.html

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

Прекратило своё существование, скорее всего, поскольку оказалось не сильно-то и нужным,

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

Главная загадка для меня:

Есть такой проект «emacs» - текстовый редактор, прилепивший к себе за годы развития 3/4 операционки, кофеварку и кухонную раковину. И что, кто-то это отрицает? Нет конечно, авторы прекрасно об этом знают, ничего не отрицают и давно уже обратили этот факт в шутку. Всем всё известно, кто хочет пользуется, кто не хочет - прохоит мимо.

И есть такой проект «systemd» - мегакомбайн, конфигуратор и запускатель всего на свете, желающий прилепить к себе 9/10 функций операционки и всю бытовую технику в доме. Монолитный и неразделяемый логически, а местами и функционально. Все всё видят и понимают и даже не осуждают. Всем всё известно, кто хочет пользуется, кто не хочет - прохоит мимо. Но авторы с маниакальным упорством это отрицают, а приспешники и воздыхатели зачем-то без устали брешут, оправдываются и разводят демагогию на 13 страниц.

Внимание вопрос: Зачем они (авторы и фанаты systemd) это делают? Моя версия: это какая-то гомосятина.

RedHat хочет завязать всех пользователей Linux на свои решения, чтобы потом впаривать им техподдержку. А фанаты просто следуют за авторами, классический трибализм. У красной шляпы все комьюнити такие.

Я пользуюсь systemd на своем арче и даже потрудился немножко его изучить, но почему-то это не мешает мне признавать, что продукт не без недостатков. Зависимости от dbus и glibc, переусложненная архитектура с кучей неатомарных операций, состояниями гонки, циклическими зависимостями, мягко говоря неполная документация, и т.д. и т.п.

Можно поподробнее про неатомарные операции и гонки? С чем сам сталкивался?

Зависимости от dbus и glibc

Кокой кошмар.

переусложненная архитектура с кучей неатомарных операций, состояниями гонки, циклическими зависимостями

С этого места поподробнее, а то сдаётся мне, что ты сам не понимаешь, о чём говоришь :)

мягко говоря неполная документация

Да ну. Примеры бы не помешали, а то у systemd одна из лучших документаций в FOSS.

не тред, а помойка

Было бы офигительно увидеть примеры - типа вот делал так с system v, а вот так теперь легко и просто делаю с systemd.

Ну, не знаю, насколько мои примеры интересны, но у нас получилось сделать следующее:

1. Гибкие системы зависимостей между сервисами и «типа-сервисами». Например, следующая штука: на одной инсталляции grpcwebproxy крутится на отдельном от основного grpc-сервиса хосте, а на другой — на том же. По условиям задачи его необходимо перезапускать, когда перезапускается основной сервис (ну, написан он так, внутрь ещё не лазили, не было времени). В случае systemd-шных unit’ов это решается добавками в /etc/systemd/system/grpcwebproxy.service.d/10-deps.conf, добавляющими нужные зависимости для данной конкретной инсталляции (в частности, PartOf). Туда же — единообразно описываемые зависимости на не-сервисные сущности типа маунтов и каталогов.

2. Объединение нескольких сервисов в таргеты.

3. Работа с cgroups и лимитами ресурсов для сервисов.

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

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

Ну, если у Вашего less-а странное управление — возьмите другой $PAGER :-)

В целом, про логи могу сказать только то, что journald работает. И логи за нужный промежуток времени можно посмотреть, указав даты. «Битые логи» (ну, физически битые) разгребать не приходилось, да, я думаю, на основном комплексе и не придется. Для сколько-нибудь серьезного комплекса все одно какой-нибудь logstash нужно ставить, и валить логи туда.

Всё равно непонятно, почему люди его так любят.

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

Серьезно? strings для чтения текстовой части бинарных логов – не костыль?

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

Ну ты же приобрёл как-то. Почему с других удивляешься?

так заепал прямо намекает, что весь его опыт базируется на запрещённых к обороту веществах ;)

Сразу видно админа мамкиного локалхоста. Journal позволяет решать задачи, которые в принципе не решаются grep/head/tail за разумное время. Понятно что на мамкином локалхосте таких задач не возникает, но при создании и развитии systemd никто и не ориентировался на проблемы начинающих линуксоидов. То, что systemd удобно использовать и для непритязательного домашнего компа - это просто приятный побочный эффект.

он помагает только мамкиным сюсямд админам, которые неспособны импортировать нормальный текстовый лог в нормальную базу данных и использовать SQL. Вместо этого эти мамкины сюсямд админы привествуют решение потера писать лог в подобие dbf-файла через встроенное в сюсямд-журнал фокспро ;)

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

у заепала бревно не в глазу, а между ушами - крепкий морёный дуб ;)

В то время как Red Hat меняет /etc/passwd на JSON, JQuery тебе скоро понадобиться вместо creutils. Надо только подождать.

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

А вместо жирнод будет браузер, как ты любишь: «Удобнее чем терминал – там есть закладки и гугл».

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

Не могу себе представить, что мог забыть инит в хомяке пользователя. Хорошо, что это опциональный сервис (хотя в федоре его, наверно, будут пропихивать по-умолчанию). И что за проблемы, если не секрет?

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