Каждый день наши компьютеры составляют более важную часть нашей жизни. Если у них есть какие-то проблемы, они влияют на наше настроение, наш юмор, хе-хе. Конечно, пользователи Windows более подвержены паническим атакам, чем если бы вирусы (да здравствует линукс!), что делать при дефрагментации жесткого диска, что при поиске и установке Clean Master для ПК (хотя здесь, в Linux, нам еще нужно очистить систему, BleachBit - одна из предпочтительных альтернатив). В последнее время у пользователей Linux появилась определенная головная боль, которая называется: Systemd
Что ж, я прочитал интересную статью о Systemd, что вроде бы не так давно в моде.
СистемаD, который некоторым кажется (и я буду использовать слова друга), одно кольцо, чтобы править ими всеми ... другие просто не подходят и не подходят, пока компьютер работает нормально, им все равно, выполняет ли init X или Y, или используется ли systemd. Этому, кто пишет, ну ... допустим я предпочитаю init, мне проще 🙂
Оставляю статью здесь:
Прежде чем начать, я должен сказать, что мне не нравится решение изменить что-то в Debian, но я ни в коем случае не планирую отказываться от своей любимой спирали. Я просто пытаюсь это сделать, если мы собираемся обсудить тему, по крайней мере, мы подготовим ее настолько, насколько это возможно, хотя я не считаю себя сторонником системы. Для демистификации systemd я буду полагаться на веб-сайт, где разработчики высказывают свою точку зрения который попал в мои руки от коллеги, который, похоже, поддерживает систему, хотя он не является пользователем Debian. Тем не менее, я думаю, что могу перейти к попытке демистифицировать то, что говорится о systemd.
systemd основан на двоичном коде
Возможно, это один из аспектов, который больше всего нас шокирует: если все основано на двоичном коде, как мы отслеживаем то, что обычно делаем, с помощью журналов? Я понятия не имею, как родился этот миф, но это не совсем правда.
systemd настраивается почти исключительно с помощью текстовых файлов. Некоторые настройки, которые также можно изменить с помощью командной строки ядра и переменных среды. В вашей конфигурации нет ничего двоичного (даже XML). Просто простой, понятный и легко читаемый текстовый файл.
Эта штука монолитная и контролирует все
Прежде чем добраться до вышеупомянутого веб-сайта, признаюсь, я сам так думал, но после прочтения того, что говорят его разработчики, мое мнение кое-что изменилось ...
Если вы соберете systemd со всеми включенными параметрами конфигурации, вы соберете 69 отдельных двоичных файлов. Эти двоичные файлы служат разным задачам и тщательно разделены по ряду причин. Например, systemd был разработан с учетом требований безопасности, поэтому большинство демонов работают с минимальными привилегиями (например, с использованием возможностей ядра) и отвечают только за очень специфические задачи, чтобы минимизировать их след, безопасность и влияние. Кроме того, параллельные системы systemd загружаются больше, чем любое предыдущее решение. Это «распараллеливание» создается путем запуска различные процессы в параллели. Поэтому видно, что systemd очень хорошо разделен на множество двоичных файлов и, следовательно, процессов. На самом деле, многие из этих двоичных файлов так хорошо ломаются, что очень полезны за пределами systemd.
Пакет, включающий 69 отдельных двоичных файлов, вряд ли можно было назвать монолитный. Однако отличие от предыдущих решений заключается в том, что мы отправляем больше компонентов в одном архиве и храним их в цепочке в одном репозитории с единым циклом выпуска.
Это не похоже на Unix
В этом, безусловно, есть доля правды. Исходные файлы systemd не содержат ни одной строки кода из исходных строк UNIX. Однако источником вдохновения является UNIX, и поэтому в systemd много UNIX. Примером может служить идея UNIX «все является файлом», которая отражена в том, что в systemd все службы отображаются во время выполнения в файловой системе ядра, cgroupfs. Итак, одной из оригинальных особенностей UNIX была поддержка нескольких рабочих мест, основанная на встроенной поддержке терминала. С systemd мы снова обеспечили многопользовательскую поддержку изначально, но на этот раз с полной поддержкой современного оборудования, включая графику, мышь, аудио, веб-камеры и многое другое. Фактически, конструкция systemd как набора интегрированных инструментов, каждый из которых имеет свои индивидуальные цели, но при совместном использовании представляет собой нечто большее, чем просто сумму частей, что более или менее составляет основу философии UNIX. Таким образом, способ обработки нашего проекта (то есть хранение большей части ядра операционной системы в одном репозитории git) намного ближе к модели BSD (которая является настоящим UNIX, а не Linux) для выполнения задач (где большая часть основная операционная система хранится в едином репозитории CVS / SVN), чего никогда не было в Linux.
В конце концов, вопрос о том, является ли что-то UNIX или нет, имеет очень мало значения. Технически превосходный, он вряд ли уникален для UNIX. Для нас UNIX оказывает большое влияние (фактически, самое большое), но у нас есть и другие факторы. Следовательно, в некоторых областях systemd будет очень UNIX, а в других - немного меньше.
Это очень сложно ...
В этом, безусловно, есть доля правды. Современные компьютеры - сложные звери, и операционная система, которая на них работает, очевидно, тоже будет, поэтому они должны быть сложными. Однако systemd определенно не сложнее, чем предыдущие реализации тех же компонентов. Это проще и имеет меньшую избыточность. С другой стороны, для создания простой операционной системы на основе systemd потребуется гораздо меньше пакетов, чем в традиционном Linux. Меньшее количество пакетов упрощает сборку вашей системы, избавляется от взаимозависимостей и большей части различного поведения всех задействованных компонентов.
Это не позволит мне использовать сценарии оболочки
Это абсолютно неверно. просто Мы не используем их для процесса загрузки, потому что мы думаем, что они не лучший инструмент для этой конкретной цели, но это не означает, что systemd несовместима с ними. Вы можете легко запускать сценарии оболочки как службы или демоны systemd, вы можете запускать сценарии, написанные на любой язык как службы systemd, поскольку systemd совершенно не заботится о том, что находится внутри его исполняемого файла. С другой стороны, мы в основном используем сценарии оболочки для наших собственных целей, для установки, сборки, тестирования systemd. И вы можете вставлять скрипты в процесс раннего запуска, они используются для обычных служб, их можно запускать на последней остановке, ограничений практически нет.
На данный момент я полагаю, что некоторые из основных убеждений, возможно, были прояснены, несмотря на то, что я не чувствовал себя сторонником перемен и имел свои опасения по поводу «демон, чтобы контролировать их всех«Я думаю, что в конце концов никто не осмелится сказать, что по крайней мере это не работает. Я даже знаю некоторых пользователей, которые замечают, что с systemd« ПК работает быстрее », но это были бы другие вещи, которые можно было бы обсудить. На данный момент мне остается только пригласить вас обсудить здесь вашу точку зрения на менеджера запуска, принятую во многих дистрибутивах, хотя сейчас самая большая реакция наблюдается в сообществе Debian, которое даже зародилось. новая вилка со всем этим. Нравится вам это или нет - это вопрос каждого, со своей стороны я просто хочу внести свой вклад в демистификацию systemd, которая в конечном итоге будет представлена в Jessie, следующей стабильной версии Debian.
Я видел статью в GUTL (которая, в свою очередь, была взята из FromAbreus)
Systemd ток?
Я из тех, кто не читает много новостей, когда что-то вызывает столько споров, я предпочитаю остановиться на более технических деталях. В том, что…. иногда мне кажется, что определенные темы перестают быть просто техническим обсуждением или дебатами и становятся похожими на сплетни о знаменитостях 🙁
Сначала открытая строка от пользователя к systemd называется systemd VS интеллект, затем Линус Торвальдс сказал, что systemd не так уж и плох как они это рисуюти по какой-то причине, если он), вилка называется бесполезный … Без комментариев… и наконец Devuan.
Не скажу, так ли плохо, как говорится, менее плохо или еще хуже. Система работает у меня без проблем, однако для личного вкуса я бы предпочел init, потому что его способ организации различных вещей (например, журналов) мне нравится больше, но эй, если systemd стал называться скаковой лошадью и должен заменить его на в этом (Будет ли это наш вьючный мул, который все делает, но не тормозит?) Ну ... чувак, пока изменение не будет очень резким, пользователи могут адаптироваться без особых проблем, и система будет работать лучше (да, лучше, мне этого мало!), Добро пожаловать 😀
Очень хорошая статья, я был с Linux Mint 17.1 Rebecca с systemd в течение нескольких дней, и я чувствую себя намного более плавным, чем в предыдущих версиях, я мало что знаю об этом, потому что я обычный пользователь, который узнает об этом, но Я буду знать, это первая статья, которую я прочитал, которая не говорит о вредителях systemD.
Что-то он будет первым, кого вы прочитаете, который не говорит о нем о вредителях, а с другой стороны, скажите мне, вы используете свой монетный двор в качестве сервера? Я имею в виду, вас не будет беспокоить, если в нем есть ошибка из время от времени, нет? Вот почему вы используете Mint, и поэтому он вас не беспокоит, он вам не нравится, но systemd вас не обманывает. Когда у вас есть ошибки и из-за этого у вас возникают серьезные проблемы в серьезной среде, это будет вас беспокоить.
Чувак, ты рекомендуешь какой-нибудь стабильный дистрибутив на основе Debian? Я мог бы использовать Debian, но после установки вам придется настроить многие вещи, кодеки и т. Д. Какой из них вы порекомендуете? Благодарю.
А как вам удалось внедрить systemd в Linux Mint? Я хотел попытаться вставить это, но я не знаю, нужно ли мне делать что-то дополнительное (к которому, теоретически, Ubuntu уже привнесла), если у вас есть какое-либо руководство по этому вопросу или что-то, что вы можете передать мне, я был бы очень признателен
Очень хорошая статья. Посмотрим, прочитают ли его антисистемные талибы (но я в этом сомневаюсь)
В любом случае, через год я увижу, как они используют SystemD, и они будут отрицать то, что говорили год назад. Так они и есть. Устойчивы к изменениям? Конечно да.
Вы считаете меня талибами за то, что я не хочу принимать Systemd, тогда я считаю вас талибами за то, что вы не хотите признать, что я не хочу принимать Systemd. Мы под рукой 😉
Однако, как сказано в конце ваших статей:
«elav: Личный блог / Twitter / G+ / Пользователь ArchLinux. Ученый-компьютерщик, любитель музыки, блоггер и веб-дизайнер. Администратор и основатель DesdeLinux.сеть. »
то есть вы используете один из первых дистрибутивов, принятых в SystemD.
привет
Хорошо, малыш.
Без слов !!!!, продолжай играть, что жизнь радужная.
Что касается комментариев, подобных вашему, дорогой Жискард, вот почему я отказываюсь от SystemD и того, что она означает.
И если после 20 лет использования и работы с Linux и для него я стану Талибаном; Что ж, пусть будет так.
Через год поговорим. И элав, я не упоминал тебя. Ты убил себя как Чакумбеле.
Посмотрим, люди читают и НЕ читают. Есть или нет Талибан против SystemD? Есть! А с другой стороны есть те, кто изо всех сил защищает это изо всех сил, как от панацеи. Кто они все такие? Нет! Не за что! Есть те, кто симпатизирует тем или другим и видит хорошее и плохое как в себе, так и в других. С ними можно без проблем разговаривать. Но они не будут отрицать, что Талибан ЕСТЬ. И из стороны в сторону. И если кто-то был уязвлен этим, не понимая, что он вполне может НЕ быть Талибаном, то я оставлю свое дело, потому что доказательства делают его виновным.
Если я веду диалог с кем-то о SystemD и с самого начала этот человек называет его не по имени, а по Systemshit или чему-то подобному, я искренне хотел бы, чтобы они сказали мне, возможно ли поговорить с таким человеком, который изначально дисквалифицирует противник. Оно не может.
В любом случае, вы должны прочитать. Посмотрим, если я подойду и скажу: «Есть еще какие-то eschejfhduf (придуманное слово), которые бьют детей, когда они покидают школу», а некоторые придут защищать «eschejfhduf», разве это не для того, чтобы подумать, что они сами?
Что ж, если кто-нибудь (не Талибан, пожалуйста, и не eschejfhduf тоже) захочет поговорить о плюсах и минусах init и SystemD (у которых есть и хорошие, и плохие), я буду счастлив быть здесь.
Привет.
Антисистема Талибана? и скажи мне, что ты? просистемный Талибан? С другой стороны, почему вы предполагаете, что мы собираемся не читать, а прямо комментировать? Кто такой консервативный Талибан, который не допускает обсуждения и говорит как LP :: «Это лучше всего, поверьте мне, я знаю, что делаю ». ?
Я прочитал всю статью и могу вам сказать:
Systemd основан на двоичном коде: True
Демистификация: ложь
LP искажает то, что сказано, а именно, что ядро systemd является двоичным, много, слишком много, чтобы зависать от PID1, сильно переплетено, настолько, что я предлагаю вам посмотреть на #devuan, сколько стоит очистить, например, logind systemd и остальные пакеты в Debian, учитывая, как ведение журнала, заменяющее PAM, связано с системой.
Конфигурация лаконична и не позволяет ВСЕГО, чего я бы не хотел, например, деактивацию журнала, поскольку вы не можете ни убить PID, ни остановить его, или что-то еще, то есть модульность?, Тот же выскочка.
===========
«Эта штука монолитная и контролирует все».
Помимо того, что это 2 или 69 двоичных файлов, они чередуются друг с другом с помощью dbus и, таким образом, со всей ОС, не позволяя легко разобщить их, самый ясный случай - это журнал, который вы не можете деактивировать, также , запуск демонов или служб осуществляется с помощью «модулей», которые представляют собой текстовые файлы, но не более того, анализируются systemd и вуаля, никаких модификаций или взломов служб, помимо установленных.
=======
«Не похоже на UNIX»
Я отвечу кратко. Он не соответствует ни LSB, ни POSIX, и сегодня разработчик Fedora, помогающий в #devuan, сказал: «Это правда, что это не так, неважно, важно то, что он может запускать вещи, которые являются POSIX, остальное, конечно, меня не интересует, какая ОС или что-то еще, главное, чтобы она работала и имеет хорошие возможности ». И почему он должен быть UNIX или UNIX-подобным: делать одно и делать это хорошо, чего не делает systemd.
===========
Однако systemd определенно не сложнее, чем предыдущие реализации тех же компонентов. Так проще и меньше избыточности »
Меньше избыточности? Они просят вас установить ДРУГОЙ системный журнал для простого текста, и они попросили его для удаленного ведения журнала до того, как появился systemd-journald-remote, то есть они запустили его в производство, не имея возможности выполнять удаленное ведение журнала без зависимости от rsyslog , что-то базовое, например централизованный вход. Тем не менее, у него нет возможности, простого логического значения, чтобы указать, хотим ли мы вывод в двоичном формате или в виде обычного текста, а также, если он собирался использовать двоичный файл, почему бы не что-то известное как Berkeley DB, чтобы его можно было прочитать из любой системы UNIX или Linux?
Просто?, Правда? посмотрите, насколько это просто: http://wiki.gentoo.org/wiki/Comparison_of_init_systems
Посмотрите на количество строк кода и файлов.
=========================
"Это не позволит мне использовать сценарии оболочки"
Это неверно, но, опять же, оно искажено, его не критикуют за то, что он не позволяет использовать скрипт bash, но за то, что он не использует их для запуска служб, поэтому его нельзя изменить, взломать и гибко, как выскочку или sysvinit. И под взломом я подразумеваю закодированный.
============================
Вы все еще думаете, что:
1.- У меня вообще нет причин
2.- Я ничего не читал и талибан ли я?
Интересно ... действительно ли я должен доверять тому, что говорит Леннарт? Если кто-то нейтральный скажет мне, что я могу принять во внимание определенные вещи, но это то же самое для меня, что Red Hat публикует что-то в защиту Systemd
Ух ты, пока кто-то здесь не скажет что-нибудь разумное, а не только страх и дезинформацию.
Статья представляет собой испанский перевод написанного Леннартом.
Без обид, но перевод, похоже, был сделан бета-версией Google Переводчика… 🙁 Мне было трудно понять некоторые абзацы; в любом случае информация ценится.
@ Чарли-Браун, это потому, что Леннарт не умеет хорошо выражать свои мысли по-английски. Вот как некрасиво читать оригинал.
Приведенные причины действительны, однако я думаю, что некоторые могут вызвать дополнительные вопросы. В любом случае, моя рекомендация тем, у кого есть возможность: перейти к первоисточнику информации. http://0pointer.net/blog/projects/the-biggest-myths.html (к сожалению для некоторых, он на английском языке), который является более полным и позволяет обосновать до 30 причин, почему использование SistemD считается благоприятным.
Упомянутая вами статья написана создателем Systemd. Очевидно, что лучше него никто не защитит свою работу, однако я приглашаю вас посмотреть это видео. http://hackingthesystem4fun.blogspot.com/2014/12/systemd-journald-centos-7-totally.html и они поделятся со мной своими выводами по этому поводу. Больше я не говорю.
elav проблема журнальных журналов, которые находятся в двоичном формате, является одним из наиболее критикуемых вопросов, даже сам Линус поднял его, когда в своем отчете признал, что systemd не так уж и плох. Также сам Линус объяснил, что вы можете создать скрипт, который берет данные журнала и помещает их в обычный текст.
Также systemd позволяет настраивать размер двоичного файла журнала, снижая риск возможного сбоя.
На самом деле, искусство, которое вы цитируете, очень несерьезно, поскольку в нем нет намека на объективность, и это даже заставляет меня задаться вопросом, настоящая ли ошибка, которую оно показывает, или это подделка (к черту проприетарное программное обеспечение, чтобы оно выдало ошибку).
все программы в какой-то момент имеют ошибки, но кажется, что они всегда будут искать пятую ногу кошки, чтобы найти что-то не так с systemd.
Например: в debian было решено, что systemd будет инициализацией по умолчанию, но это не предотвращает использование sysvinit, openrc или upstart, и вы скажете мне хорошо, что да, но вы не можете полностью удалить systemd, и я отвечу, что это то же, что и в debian wheezy, где вы можете запускать openrc, systemd или upstart, но под sysvinit
PS: Я не хочу представить, как они собираются сойти с ума от kdbus и его интеграции с systemd на уровне ядра Linux http://kroah.com/log/blog/2014/01/15/kdbus-details/
Если это возможно. Кроме того, я планирую официально отказаться от обсуждения Systemd. Что бы ни случилось 🙂
@rolo: сбой задокументирован, ему были представлены несколько отчетов об ошибках, ему показали видео, а теперь говорят, что это подделка. Если вы хотите быть уверенным, следуйте инструкциям и посмотрите, что произойдет. Теперь вот больше информации по этому поводу, придуманные ошибки? Я так не думаю.
https://bugzilla.redhat.com/show_bug.cgi?id=958321
https://bugzilla.redhat.com/show_bug.cgi?id=1054929
https://bugzilla.redhat.com/show_bug.cgi?id=1055570
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=74280
https://bugs.archlinux.org/task/32191
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=64116 (Леннарт и его замечательные объяснения)
https://bugzilla.redhat.com/show_bug.cgi?id=974132
https://bugzilla.redhat.com/show_bug.cgi?id=1157350
То, что упоминается в видео, безусловно, любопытно. Как разработчику нам всегда говорят, что одна деталь не должна влиять на всю систему / программу, например, если запрос выбора к базе данных завершается неудачно, почему вся программа должна давать сбой? То же самое и с SystemD: если он терпит неудачу из-за того, что другие терпят неудачу, я не знаю, насколько хорошо это сделано. Очевидно, что есть случаи, когда отказ фактически является отказом системы, но чем более изолированными будут свойства программы, тем лучше будет продукт.
Теперь атаковать программное обеспечение с его слабой стороны не ново, это довольно распространенная практика, и на самом деле это должно выполняться с каждой программой, поэтому то, что SystemD попадает в список, является веским доказательством того, что SystemD Это не то, что есть. сказал или заставил поверить.
Чем больше вещей становится взаимозависимыми с SystemD, тем хуже становится. Если до монтажа устройство не обрушивалось на систему, то теперь все может выглядеть не так хорошо.
SystemD неплох, я не ненавижу его, но это не то, во что многие хотели бы поверить. У него есть преимущества, но ничего, чего не было и не могло быть у Upstart, конечно, Canonical была задействована, и никто больше не хотел обращать на это внимание.
Привет.
но в этом видео я ни разу не знаю, что система дает сбой. этот тип модифицирует двоичный файл информации журнала для генерации ошибки, но дело в том, что каждый раз, когда он входит в systemd.
Насколько я понимаю, если вы ограничите размер двоичного файла журнала, когда он достигнет предела, он создаст еще один и так далее. снижение вероятности повреждения всех данных.
Давайте проясним ... Кто бы мог подумать об изменении файла журнала? xD
@Jorgicio 4 декабря 2014 6:03
Давайте проясним ... Кто бы мог подумать об изменении файла журнала? xD
Если вы иронично сказали ... все хорошо, я понял :)), но если вы действительно спросили, я изложу свою точку зрения.
Для меня ясно, что это не баг, а фича !! Идея состоит в том, что при повышении привилегий при удаленном доступе для тех, кто согласен удалить журнал, будет очень легко просто отредактировать его, чтобы повредить его, а для systemd удалить его как поврежденный и таким образом избежать обнаружения в нем. удаленный доступ.
Назовите меня параноиком, но у меня нет другого образа мыслей ... это не ошибка, это особенность, и именно поэтому они не соглашаются исправлять эту ошибку.
uff теперь все блоги linux публикуют 200 статей о systemd до такой степени, что я уже знаю почти все аргументы против и за xD.
и постепенно меня убедили некоторые антисистемные аргументы и те, которые я видел (если что-то не так, пожалуйста, поправьте меня)
Я даже видел там статью о том, как вывести из строя всю систему при редактировании двоичного журнала и что она не дает никакой информации о том, что файл поврежден.
отсутствие ясности в журналах
команда разработчиков, которая часто игнорирует сообщения об ошибках
Такой большой размер и включение такого количества вещей в init делает систему намного более нестабильной, и если мы добавим ошибки, подобные упомянутой выше, это сделает систему без стабильности, которую так характеризует linux.
он называется модульным, но его части не могут работать без других частей той же системы.
разработка, которая в конечном итоге порождает зависимости при программировании, делая такое программное обеспечение, как gnome, трудно переносимым для систем без systemd.
он заменяет части (networkd, logind и т. д.), которые работали и получали обслуживание в течение многих лет, и меняет их на новые без какой-либо необходимости, которые, как правило, имеют гораздо больше ошибок.
С тех пор, как я использовал дистрибутивы на основе Arch (Manjaro, Bridge Linux, Antergos), которые явно используют systemd, я должен сказать, что у меня нет претензий по поводу его использования и обработки. Запускать службы очень просто - особенно в Bridge, где по умолчанию отключены bluetooth или модем. Помимо ошибки, связанной с hwdb.bin (https://bbs.archlinux.org/viewtopic.php?id=189536) Проблем у меня не было много. Конечно, я не думаю, что это общее мнение, но лично у меня нет претензий 🙂
Мне не нравится идея, что компания (Red Hat), обвиняемая в сотрудничестве с АНБ (черный ход и контроль США), создаст систему, с помощью которой все контролируется. Кольцо, чтобы контролировать их всех, при необходимости связать их в темноте ..
С другой стороны, я должен признать, что Intel IRIS PRO 5200 работает для меня лучше, и почти никогда, если не больше, моя графическая система ломается, когда я запускаю openSUSE 13.1. И да, все лучше, запускается и выключается намного быстрее. Какую пользу мне помог простой пользователь.
Я выделяю важную часть
Если кто-то обвиняет вас в продаже наркотиков, вы автоматически являетесь торговцем наркотиками?
@juanfgs
Наркоторговец нет .... сообщник да.
Боже ... Я бы оскорбил тебя, но твои слова делают это за тебя.
Просто поясните, что systemd написан, и именно так это нужно делать.
Орфография
Да, написано systemd, а не система D или System D, или даже SystemD. И это тоже не система d. Почему? Потому что это системный демон, а в Unix / Linux они пишутся в нижнем регистре и имеют суффикс в нижнем регистре d. И поскольку systemd управляет системой, она называется systemd. Это так просто. Но опять же, если все это кажется вам слишком простым, назовите это (но никогда не пишите по буквам!) Системой Пятьсот, поскольку D - римское число для 500 (это также проясняет отношение к Системе V, верно?). Единственная ситуация, когда мы считаем приемлемым использовать заглавную букву в имени (но это тоже не нравится), - это если вы начинаете предложение с systemd. В праздничные дни вы также можете написать это слово sÿstëmd. Но опять же, Système D - это неприемлемое написание и нечто совершенно иное (хотя вроде бы подходящее).
http://freedesktop.org/wiki/Software/systemd/
Здесь тоже? Вы помещаете это в GUTL ... но, черт возьми, все говорят, что Linux, а не GNU / Linux, то же самое и с SystemD.
Я говорю вам, что нет необходимости использовать систему журналов или cron, которые предоставляет systemD, вы можете следить за syslog-ng и cronie для этой или других альтернатив
Я использую systemD в ArchLinux, так как я был в aur, и мне кажется, что с ним проще работать, чем с производной формой debian и redhat, в ней есть много консольных команд, которые избавляют вас от редактирования текстовых файлов и упрощают сборку скриптов. (помните, что в арке все устанавливается консолью)
И что не менее важно, система запускается быстро, в Arch вы можете запускать службы параллельно при запуске системы, но это рискованно.
Что я считаю плохим в этой проблеме, так это то, что большинство принимает чью-то сторону, или вы сторонники системы, или противники системы, и я думаю, что в этом есть свои плюсы и минусы, я пользователь и начал немного играть с systemd, действительно Хорошие вещи в том, что запуск выполняется быстрее и проще, чем остальная часть инициализации, хотя вопрос журнала меня тоже очень беспокоит.
Я понимаю, что те, кто действительно могут сказать, хорошо это или плохо, - это системные администраторы или эксперты в этой области, но мне кажется, что возня с systemd некоторое время назад перестала быть чем-то техническим и стала чем-то более "показательным", для со своей стороны я немного против, но я не считаю себя противником или за
@KZKG_Гаара
Я вижу, что многое из того, что вы здесь говорите, совпадает с тем, что Леннарт опубликовал в своем блоге, точнее в этой записи: http://0pointer.de/blog/projects/the-biggest-myths.html.
Конечно, в посте были определенные "разъяснения" и оставлено определенное техническое содержание, чтобы его было легко усвоить для тех, кто собирается его читать, но мы будем серьезными и искренними, даже если правда болит: в systemd есть много того, чего Леннарт отрицает, и многое другое. И в этом смысле я объясняю по частям.
1.- Леннарт говорит, что у него нет вздутия живота и что у него нет синдрома высокого уровня NIH (не изобретенного здесь синдрома). Если да, пожалуйста, объясните мне: почему у init должно быть управление сетью (systemd-networkd), dns (systemd-networkd), m-dns (systemd-networkd), журналы (journald), coredump (systemd -coredump), отладки (systemd-coredump и journald), acpi (logind), повышение привилегий (logind), контроль ntp (systemd-timesyncd), контроль над dev (systemd взял на себя все функции udev), контроль над / dev / random (случайное число генератор) и последний контроль над TTY (systemd-consoled)? Разве не было МНОГО инструментов, созданных для таких целей, что systemd теперь добавляет свои собственные инструменты с эксклюзивным доступом (случай journald)? Какое логичное и приемлемое объяснение вы даете мне, что инициализация может нарушить отладку ядра и командную строку? Добавьте к этому контроль над kdbus, следующим IPC, который будет интегрирован в ядро. Наверняка здесь мне скажут: «Но вы можете установить другой инструмент, чтобы все это контролировать». И если это правда, но многие из этих инструментов получают только поток данных, созданный systemd, как в случае syslog и rsyslog, которые подключаются к данным / потоку, который предоставляет journald, чтобы другие инструменты могли ВИДЕТЬ, какой диск journald , в конце концов, это просто означает, что у вас есть два инструмента, которые делают одно и то же, и один из них - ящик Пандоры. (Пожалуйста, не говорите мне, что код можно проверять, потому что я приглашаю кого-то «выкурить» код journald и его фреймворк с помощью systemd и других связанных инструментов)
2.- Леннарт также сообщает нам, что systemd предлагает поддержку сценариев SysV и LSB. Это «наполовину правда», так сказать, «белая ложь», потому что правда в том, что systemd-214 не предлагает поддержки сценариев bash, SysV или LSB, и об этом говорится в примечаниях к выпуску для этой версии.
3.- Какой systemd не переносится? Это еще один спорный вопрос. В BSD это не работает, в BSD нет Cgroups среди других инструментов, которые необходимо запустить systemd. Но это сделано по причине дизайна systemd, а не потому, что он не переносится. До тех пор, пока ядро BSD не будет соответствовать минимуму для его поддержки, systemd не будет работать на этой платформе, и это не является чьей-либо ошибкой, только BSD не представляет интереса, как и Леннарта. Это так просто. Теперь поддержка других библиотек C - это другое дело, хорошо известные проблемы с glibc (просто создайте ядро вручную, чтобы увидеть количество опций и обходных решений, которые были сделаны, чтобы избежать этих деталей, особенно для glibc 2.3, 2.5 и 2.11, среди других недостатков, которые glibc затягивал на протяжении многих лет), но на этом все не заканчивается, сам Леннарт сказал, что он предпочел создать свою собственную библиотеку libc, потому что для его группы это намного быстрее. это, чем читать код, уже созданный (и, кстати, задокументированный), но это еще не все, они планируют удалить glibc и использовать свой libc не только для systemd, но и для Fedora, сделав его стандартным для конструкции всех их пакетов. NIH Где? Похоже, старый добрый Леннарт любит троллить и по-крупному.
4.- Этот systemd не является монолитным, потому что он разделен на 69 двоичных файлов. Да ладно, это спорный вопрос. systemd имеет 69 двоичных файлов, которые выполняют разные задачи, но эти двоичные файлы передают информацию о своей задаче в systemd, поэтому в случае сбоя одного из них шансы взломать систему значительно возрастают. Это хорошо задокументировано, отчеты об ошибках изобилуют такими проблемами и даже более простыми проблемами, на самом деле до глупости простыми. systemd может быть разбит на сотни двоичных файлов, но пока ваше ядро находится под контролем, риск поломки сохраняется и увеличивается, и если вы мне не верите, прочтите отчеты об ошибках и получайте удовольствие.
Обратите внимание, что здесь я не комментировал ничего, что systemd является мусором, я сделал только «технические» комментарии (очевидно, что разговор о технических вещах становится очень сложным) и действительный, подкрепленный информацией, легко доступной в Интернете. Теперь: какой Linux нужен стандартный init? Да, это, безусловно, будет чем-то очень ценным для сообщества. Какой systemd - это решение? Нет, хотя он близок, у него, безусловно, есть много положительных моментов, но его вирусное распространение и количество вещей, которые он действительно увеличивает, риск того, что может пойти не так и в конечном итоге нанести вред сообществу.
PS: Я оставляю материал, где вы можете подтвердить то, что я говорю, прочитать его будет достаточно иллюстративным, и я вижу, что я не включаю блоги или что-то в этом роде, чисто личную и основанную на критике. С уважением.
http://lists.freedesktop.org/archives/systemd-devel/2014-June/019925.html
http://cgit.freedesktop.org/systemd/systemd/commit/?id=ce7b9f50c3fadbad22feeb28e4429ad9bee02bcc
http://lists.freedesktop.org/archives/systemd-devel/2013-November/014808.html
https://bugzilla.redhat.com/show_bug.cgi?id=1057883 (@elav, может быть, ты чувствуешь себя идентифицированным)
https://code.google.com/p/d-bus/source/browse/kdbus.txt
https://github.com/gregkh/kdbus
http://lists.freedesktop.org/archives/systemd-devel/2013-March/010062.html
Аминь брат .. аминь ..
Я до сих пор не вижу веских причин не применять systemd. Вы просто со страхом интерпретируете то, что видите, что приводит к преувеличению. Ни явных и четко определенных преимуществ и недостатков.
Кроме того, эта интеграция позволяет стандартизировать, о чем вы даже говорили. Не только Red Hat работает с systemd, но и разные компании и волонтеры из других дистрибутивов.
Думаю, ошибка в том, что работа systemd не изучена должным образом.
Я действительно вижу веские причины в анализе Юкитеру. Заметьте, что вместо страха я вижу строгость, точность и ясность. Это должно быть проблема окулиста.
Это не страх (я не боюсь части кода) и не преувеличения (все, что я здесь сказал, задокументировано, и я передал много информации, подтверждающей это, информация, которая, кстати, выходит из списков и из разума / голоса / собственного почерка Леннарта, а не из комментариев блоггера), ЭТО РЕАЛЬНОСТЬ.
systemd делает все это и многое другое, и это что-то ОБЕСПЕЧИВАЮЩЕЕ (другое понятие, чем боязнь), потому что он, безусловно, принимает атрибуцию и делает то, что в данный момент можно сделать другими способами и что, кстати, работает лучше и стабильнее. . systemd очень похож на Windows, и это не может быть скрыто, просто знайте, что делают userinit.exe, svchost.exe, smss.exe и другие зависимости, и сравните их с systemd, сходство настолько велико, что это плохая идея. Конечно, systemd может иметь лучшее качество, чем его аналог для Windows (или может произойти обратное, никто точно не знает, если вы не программируете для Microsoft), но вы не можете обвинить меня в ПРЕВЫШЕНИИ и СТРАХЕ, когда вы читаете самого Леннарта. о создании совершенно новой библиотеки C, потому что ему надоел Glibc, и для ñapa, бросив небольшую и незначительную подсказку, что эту libc можно использовать для сборки всех пакетов Fedora. И если вы думаете, что это ложь и что я преувеличиваю, я оставлю вам сообщение по этой ссылке: http://lists.freedesktop.org/archives/systemd-devel/2013-March/010062.html (по-английски)
Теперь скажите мне, не будет ли преувеличением сказать перед всеми этими вещами, что как только Линус решит, что CONFIG_VT как есть, он должен выйти из ядра (ситуация, которая существует уже давно) и передать его в пользовательское пространство, не происходит сумасшедших вещей, например, если systemd-consoled является сильной зависимостью почти для любой установки Linux (что-то должно обрабатывать VT, вам не кажется?), это не поставило бы в центр внимания различные дистрибутивы, не относящиеся к systemd. заставить переключатель. Если вы думаете, что это натянуто, позвольте мне сказать вам, что вы понятия не имеете, на что способен и что делает Леннарт, поскольку его последние изменения влияют на развитие форка udev, Gentoo eudev, и он будет продолжать делать это со своими угрозами. под столом (чтобы позже пожаловаться, как он это делал в Google+)
@xiep Я не могу больше согласиться с вашим комментарием.
Че Юкитеру, в вашем длинном заявлении опущен тот факт, что электронное письмо, на которое вы ссылаетесь на libc, является апрельской шуткой, посмотрите на сноску и посмотрите на дату (31 марта, вероятно, 1 апреля по часовому поясу Леннарта)
Практикуйте свой английский-фу, потому что он водянистый и ставит под сомнение все ваши «исследования».
@juanfgs, кажется, вы единственный, кто читает, по крайней мере, я аплодирую вам за это, но вам нужно прочитать что-то очень важное, что есть в моем комментарии, это не имеет значения, я помещу это здесь:
»NIH Где? Кажется, старый добрый Леннарт любит троллить и по-крупному ».
Я не думаю, что он написал это по невинной причине, он знал о том, что это была очередная шутка Леннарта по поводу Дня дурака (плохое настроение), а также о своей страсти к преобразованию /, / и т.д. и всего остального в / Linux. 🙂
PS: Спасибо, но мне не нужно практиковать свой английский, я использую язык с 6 лет.
аааа а все остальное правда, проверьте это 🙂
Это откровенная сенсация, вы говорите, что основаны на фактах, но на самом деле вы следуете своей догадке, что этот парень плохой и хочет захватить мир, и вы искажаете факты, чтобы отразить свою речь. Это то, что меня очень беспокоит в антисистемных людях: они не жалеют слов, когда дело доходит до искажения фактов и утверждения полуправды, конечно, загруженных их мнением.
Мое «практическое правило» в этих случаях - это просто следующая логическая разбивка, начиная с предпосылки, что
- Я веб-разработчик / настольных приложений или cli
- Я никогда не писал систему инициализации.
- Я не поддерживаю дистрибутив.
проверьте, есть ли у собеседника:
- создал систему инициализации
- активно поддерживает систему инициализации дистрибутива
и реальность такова, что большинство антисистем не проходят этот тест, но все же они - горстка людей, которые по какой-то причине ЗНАЮТ БОЛЬШЕ, чем люди, стоящие за ними: Debian, Fedora, Archlinux, ядро Linux, весь проект GNOME, возможно, Проект KDE тоже, так как они не жаловались на systemd, SUSE и т. Д.
Несмотря на это, его ядовитая и язвительная речь - единственное, чего он добивается, - это порождать разобщенность, проблемы и прочее. Дело в том, что я не могу дождаться, когда они наконец переключатся на BSD, поскольку они угрожали со стороны Xorg, NetworkManager, PulseAudio, и я не знаю, из-за чистого технического незнания или из-за того, что они не будут жаловаться на это.
@juanfgs, я ловлю вас на слове именно по этому поводу:
«И реальность такова, что большинство антисистем не проходят этот тест, тем не менее, это горстка людей, которые по какой-то причине ЗНАЮТ БОЛЬШЕ, чем люди, стоящие за ними: Debian, Fedora, Archlinux, ядро Linux, весь проект GNOME. , вероятно, проект KDE, так как они не жаловались на systemd, SUSE и т. д.
Несмотря на это, его ядовитая и язвительная речь - единственное, чего он добивается, - это порождает разобщенность, проблемы и прочее. Дело в том, что я не могу дождаться, когда они наконец переключатся на BSD, поскольку они угрожали со стороны Xorg, NetworkManager, PulseAudio, и я не знаю, из-за чистого технического незнания или потому, что они не будут жаловаться на это. "
Итак, ПО СМОТРЕНИЮ, все мы, антисистемы, ядовиты и ядовиты, поэтому единственное, чего мы добиваемся, - это разобщенность, проблемы и так далее. Позвольте мне сказать вам, что это величайшее возмущение, которое мне удалось здесь прочитать. Я не знаю, почему просистемные люди беспокоятся, когда обнаруживаются структурные проблемы системы, которые, очевидно, повлияют на них в какой-то момент, потому что сейчас с ними ничего не произошло, но в какой-то момент они будут. так и будет, и тогда какой-нибудь антисистемный помощник напомнит им слова, которые они говорили много раз, и никто их не останавливал, и, возможно, какой-нибудь другой антисистемный инструмент им поможет.
Лично мне не нравится systemd, но это не значит, что я не использую init, я должен, потому что именно в моей работе, если мне приходится трогать машину с этим init, я должен иметь знания, как с ним обращаться. это. Кроме того, лично я также использовал его с тех пор, как пришел в Archlinux, и даже в Debian и Gentoo, так что не говорите мне, что мое видение искажается из-за того, что я не использую systemd, я использовал его и знаю, насколько это отстойно. , и если мне придется помочь кому-то здесь на форуме DesdeLinux или в IRC, или в списке Debian (это дистрибутив, в котором я работаю дольше всех и до сих пор использую его в своей работе) я сделаю это с удовольствием, потому что именно если мне что-то и нравится в сообществе Linux, так это то, что несмотря на разницу, это всегда помощь.
Теперь переключиться на BSD возможно, но я сделаю это только в том случае, если systemd станет настолько опасным, что не позволит мне использовать какие-либо другие варианты, а пока я остаюсь на Linux, отключая все это безумие, включая многие из Cgroups вещи.
!=
Вы снова перекручиваете слова, чтобы они соответствовали вашей речи. Вы очень хороший материал для политика / журналиста.
Уточняю, моя проблема не в том, что они упоминают технические проблемы Systemd, дело в том, что они много раз нагружают свою речь ложью, а именно:
Что, если systemd заставит вас использовать сервер microhttpd (который является дополнительным модулем, НЕ установленным по умолчанию), что если systemd является одним двоичным файлом, этот systemd будет закрыт, потому что lennart оплачивается Microsoft, эти двоичные журналы Они обязательны. Никто не хочет systemd, и его принятие осуществляется политическим лобби.
Вот что шокирует ложь. Если бы это было разумное обсуждение, оно того стоило бы, но это просто хороший FUD.
То, что вам это не нравится, кажется мне идеальным, мне не нравится много программного обеспечения, даже языки программирования, дистрибутивы и прочее, но я ничего не выдумываю на этот счет и не подобострастно читаю то, что хочу прочитать, и загружать свои высказывания личными переживаниями, чтобы навредить имиджу людей, которые его развивают.
@juanfgs извините, но я не тот, кто называет определенную группу людей «ядовитыми и ядовитыми» просто потому, что им не нравится какое-то программное обеспечение.
Опять перекручивание приговоров, чтобы стать жертвой.
@juanfgs еще раз говорю вам, что вы сказали, проверьте свои слова, я не искажаю ваши слова, я просто скопировал / вставил ваши слова в комментарии 59.
Я цитирую свой текстовый комментарий capo, тот, который вам нужно прочитать снова, - это вы, потому что вы не хотите понимать, или вы не знаете, как спорить. Вы вырываете вещи из контекста и интерпретируете их так, как они вам воспеваются. Итак, если вы хотите жить в мире, где вы чувствуете себя оскорбленным из-за того, что ваши аргументы оспариваются, Леннарт, Red Hat и Microsoft преследуют вас, потому что вы предпочитаете верить в это.
Кратко, потому что я понимаю, что вы неразумный человек, потому что не хотите понимать, вы хотите интерпретировать вещи так, как считаете нужным.
Если вы хотите, чтобы вас обидели, обижайтесь, но это ваша проблема, а не весь остальной мир.
@juanfgs Меня не беспокоят ваши комментарии, я действительно не вижу причин, мы спорим, цивилизованные люди спорят, не беспокоясь об этом (я так думаю).
Теперь, если вам нравится навешивать ярлыки, предубеждать (или как вы хотите это назвать) людей за их речи или действия (возможно, вам следует прочитать мой комментарий № 64 и измерить его масштаб), это ваша проблема, ограничьтесь этими действиями. по отношению к себе и оставьте других вне этого мешка.
Привет.
«Большая часть антисистемного», «почти все», «все», «какая-то часть антисистемного» ... мы отклоняемся, Мариано, мы отклоняемся. В данном случае: я нигде не вижу, чтобы Юкитеру выступил с сенсационной речью, основанной на догадках (ссылка на его анализ таким образом действительно имеет что-то искаженное), напротив, он разработал веские аргументы о недостатках systemd на основе соответствующие вопросы и материалы, взятые из списков рассылки и отслеживания ошибок (плюс вежливо и цивилизованно). Возможно, по этой причине он кого-то раздражает, и они нападают на него при первом же комментарии, чтобы дискредитировать и дисквалифицировать (на этот раз ядовитым образом).
Если вы видите, что дискурс большинства антисистемных людей является ядовитым и ядовитым, то в дискурсе некоторых просистемных (я не знаю, составляют ли они большинство или меньшинство) я вижу истерию и преследование тех, кто именно они приводят веские аргументы на фоне всего шума. В моей стране это называется беспокоящим инакомыслием.
У вас дела с systemd? Отлично, мне это кажется отличным, но пусть те, кто думает иначе, выскажут свои оговорки (операционная система может работать иначе).
привет
Да, кстати, почему любая ошибка systemd раздувается до такой степени, что тратит впустую весь компонент, а другие, такие как GCC, glibc или даже ядро, до сих пор не подвергались критике за многие из своих ошибок?
Вы сами сказали, glibc уже давно таскает проблемы. Llvm со временем доказал свои преимущества перед GCC. И здесь я не вижу такой же критики.
Почему бы не сделать то же самое с другими проектами?
Для меня это просто коллективный и иррациональный страх.
В Glibc есть ошибки, которые никто не может скрыть, есть огромные ошибки Glibc, которые влияют на ядро и сотни исполняемых файлов. Разница между Glibc и systemd заключается в том, что первый - это база, на которой ТЫСЯЧИ программных проектов могут быть преобразованы в двоичные файлы, а systemd - это init, цель которого - быть стабильной, проверенной и практически безошибочной частью. Мало того, Glibc должен адаптироваться к сотням различных аппаратных архитектур (ЦП), к различным флагам оптимизации и уникальным характеристикам ЦП, к различным формам оптимизации программного обеспечения, а также к гораздо более трудной и сложной работе, чем у systemd. Я действительно не вижу способа провести сравнение двух проектов в одном масштабе.
То же самое и с GCC, GCC - это компилятор, который, кстати, поддерживает множество языков (всего 13, включая неофициальные), и имеет характеристики, очень похожие на Glibc, поддерживает множество архитектур (70 архитектур для версии 4.9), бинарную оптимизацию флаги, флаги оптимизации процессора и многие другие функции. Сейчас они на том же уровне сложности, компилятор с init. Ответ более чем очевиден, начиная с того, что systemd находится на C, а большая часть кода GCC находится на ассемблере, или вам нужно использовать ассемблер, чтобы заставить вещи работать в двоичном формате, что немного «сложно сделать».
Что не так с GCC и Glibc? Очистить. Даже Линус дал им свою атаку, но в GCC и Glibc у них есть кое-что положительное, что в systemd о них часто забывают, то есть сообщается об ошибке, обнаруживается ошибка, исправляется ошибка.
- пожалуйста, объясните мне: почему инициализация должна контролировать:
сети (systemd-networkd),
DNS (systemd-networkd),
м-днс (systemd-networkd), л
огс (журнал),
дампы ядра (systemd-coredump),
отладки (systemd-coredump и journald),
acpi (logind), повышение привилегий (logind),
ntp (системный-timesyncd),
dev (systemd взяла весь функционал у udev),
de / dev / random (генератор случайных чисел)
TTY (системный)?
Тема 100000 повторяется и повторяется, что вам нужно сказать, так это то, что systemd может работать без них, на самом деле в debian нет даже половины из тех, что вы упомянули
точно так же это лишь характеристика его широкого подхода
lennart: Что ж, systemd разбивает то, что он должен делать, на множество различных компонентов (сегодня более 90 двоичных файлов). Каждый работает с минимально возможным количеством привилегий.
Я полагаю, это не слишком большая разница в coreutils, который также имеет большое количество компонентов в одном пакете. И coreutils, вероятно, один из главных проектов, благодаря которому Linux ощущается как UNIX-подобная операционная система, верно?
Но да, systemd сложнее sysvinit, без вопросов. За последние 40 лет вычислительной техники многое изменилось, и многие из них действительно требуют определенного уровня сложности, чтобы справиться с этим ... Есть очень небольшой способ обойти это.
Потому что вы не получите этого бескомпромиссного с помощью freebsd, который делает то же самое, но со своими инструментами и без разрешения использования других, чего нельзя сказать о systemd.
- Разве не было уже МНОГО инструментов, созданных для таких целей, что systemd теперь добавляет свои собственные, некоторые с эксклюзивным доступом (case journald)?
Я не буду отрицать, что тема журнала сохраняет информацию в двоичном формате - это самое слабое, что нужно защищать, но это не конец света, их можно сохранить в виде обычного текста.
- Какое логичное и приемлемое объяснение вы даете мне, что инициализация может нарушить отладку ядра и командную строку?
Ммммммммммм …………………. сломать ядро ……. 5000000 вещей могут сломать ядро
- Добавьте к этому контроль над kdbus, следующим IPC, который будет интегрирован в ядро.
По словам Леннарта, это положительно влияет на разработчиков, и systemd предоставит администраторам инструменты для открытия dbus, а также интерфейс журналов и сетевых шин.
- Наверняка здесь мне скажут: «Но вы можете установить другой инструмент, чтобы все это контролировать». И если это правда, но многие из этих инструментов получают только поток данных, создаваемый systemd, как в случае syslog и rsyslog,… .. это означает только то, что у вас есть два инструмента, которые делают то же самое, и один из это ящик Пандоры. (Пожалуйста, не говорите мне, что код можно проверять, потому что я приглашаю кого-нибудь «выкурить» код journald и его фреймворк с помощью systemd и других связанных инструментов)
здесь мы вводим теорию заговора !!!!! это тощее бесплатное программное обеспечение, ничего не скрыто
3.- Какой systemd не переносится? Это еще один спорный вопрос. В BSD это не работает, в BSD нет Cgroups среди других инструментов, которые необходимо запустить systemd. Но это сделано по причине дизайна systemd, а не потому, что он не переносится. До тех пор, пока ядро BSD не будет соответствовать минимуму для его поддержки, systemd не будет работать на этой платформе, и это не является чьей-либо ошибкой, только BSD не представляет интереса, как и Леннарта.
Что ж, это не совсем правильно, разработчики bsd делают что-то похожее на systemd, что сам Леннарт выделил в своей учетной записи g +
https://plus.google.com/115547683951727699051/posts/g78piqXsbKG
https://www.youtube.com/watch?v=Mri66Uz6-8Y
4.- Этот systemd не является монолитным, потому что он разделен на 69 двоичных файлов. Да ладно, это спорный вопрос. systemd имеет 69 двоичных файлов, которые выполняют разные задачи, но эти двоичные файлы передают информацию о своей задаче в systemd, поэтому в случае сбоя одного из них шансы взломать систему значительно возрастают. Это хорошо задокументировано, отчеты об ошибках изобилуют такими проблемами и даже более простыми проблемами, на самом деле до глупости простыми. systemd может быть разбит на сотни двоичных файлов, но пока ваше ядро находится под контролем, риск поломки сохраняется и увеличивается, и если вы мне не верите, прочтите отчеты об ошибках и получайте удовольствие.
Если вы используете sysvinit и ваш TTY dev acpi ntp ломается, ваша система ломается, не пугайтесь.
Монолитный - это freebsd, и вы ничего не говорите
@роло
Теперь перечислите мне, какие дистрибутивы взяли systemd и создали эти 90 двоичных файлов в отдельных пакетах, это будет 91 пакет с systemd.
И при установке systemd он не запрашивает у меня какие-либо из этих 90 пакетов как зависимости.
Серьезно, и я снова настаиваю ... пожалуйста, передайте мне параметры –configure-help, которые я хочу сделать, чтобы 91 пакет компилировался вручную с помощью make.
Нет хуже слепого, чем тот, кто не хочет видеть ... пацаны, это вода и масло, кажется, что еще есть упрямые люди, которые не видят реальности того, что гнался за redhat.
@rolo Я хочу, чтобы вы установили systemd и удалили journald, systemd-udev и coredump, а также напрямую использовали такие параметры, как eudev и syslog, чтобы проверить, сможете ли вы.
Этот комментарий не мог рассмешить меня более серьезно, я умираю. 😀
Если серьезно, они действительно утруждают себя чтением, вместо того, чтобы засовывать луч в глаза.
Кроме того, никто не забывает, что Кей Сиверс не только сломал командную строку ядра, но и хотел закрыть ее, в конце концов, «дженерик - это родовой».
Другими словами, по вашему мнению, тот факт, что два процесса передают информацию, делает их настолько связанными, что факт сбоя одного из них приводит к тому, что другой имеет высокую вероятность сбоя ... из какой теории разработки программного обеспечения вы это взяли? Я согласен с @pamp, что вы говорите из иррационального и необъективного страха.
И ваш другой большой вопрос, почему systemd должен контролировать так много вещей? Простой ответ: поскольку с sysvinit и всеми другими преимуществами init, недавно появившимися в ядре Linux, тратятся зря, до тех пор, пока их никто не использует в пользовательском пространстве, они «злятся» (как мы говорим на Кубе ... ну , потрачено впустую) без кого-либо, и они дают большие преимущества в эффективном использовании аппаратных ресурсов (ЦП, ОЗУ, ввода-вывода и т. д.), включая контрольные группы. Что именно systemd делает, так это ставит эти полезные функции ядра Linux на службу пользователю, но для этого он должен быть тем, кто запускает этих демонов.
Я думаю, вы неправильно прочитали и проанализировали (анализ важен) или просто не дали себе возможности сделать это. То, что два процесса передают информацию, не является причиной поломки системы, однако, когда у вас есть двоичные файлы с динамическими действиями, такими как управление сетью, журналы или coredump, передача информации непосредственно в init, что-то может пойти не так, и они пойдут не так, потому что если некоторые из двоичных файлов сломаются, шансы сломать остальные намного выше, и это вполне реально, и это произошло, недавно произошел сбой командной строки ядра, проблемы acpi, которые были у разработчиков Nvidia благодаря systemd-212, все это образец того, что я говорю.
@Дарьем
Если вы не можете скомпилировать каждый из этих двоичных файлов в отдельные пакеты, вы заставляете это делать, потому что хотите, чтобы один был установлен, вам нужно установить их все, при установке их всех оказывается, что вы наступаете на другие пакеты, которые не могут быть установлены, потому что части of systemd занимают эти места.
Какой смысл разбивать большой исполняемый файл на несколько меньших, если в конце у вас нет пакета для каждого, который позволяет вам устанавливать их по отдельности.
Я возвращаюсь, чтобы сделать общий запрос ко всем продвинутым пользователям systemd, рассказать мне, как скомпилировать эти 90 модулей и создать 90 пакетов, которые, если я захочу их установить, а в противном случае я использую программы, которые использовал.
Очень плохое молоко все это ... кажется, люди systemd думают, что все пользователи gnu / linux дураки.
Для справки, я использую тестирование gentoo, и несколько месяцев назад я переключился на systemd, но не смог с journald, что заставило меня вернуться к openrc быстрее, чем требовалось, чтобы переключиться на systemd.
Чтобы продолжить наблюдение, как обстоят дела с systemd, у меня на ноутбуке есть archlinux, который скоро будет выпущен для gentoo… Конечно, стабильный.
@anonymous, я просто хочу посмотреть, как проблема TTY будет развиваться в Linux. Когда выйдет код CONFIG_VT, в пользу разделения VT на две хорошо дифференцированные части (пространство ядра и пространство пользователя) нам понадобится какой-то инструмент для управления VT из пользовательского пространства, и там systemd-consoled может играть в сильную зависимость, которая тянет за собой остальную часть дистрибутивов к необходимости установки компонентов systemd, просто чтобы система могла работать. То, что я говорю, не является преувеличением, это очень, очень большая возможность и действительно тревожит. Есть и другие проекты, такие как KMSCon, но если большинство настольных компьютеров и дистрибутивов выберут systemd, такие вещи, как KMSCon, могут умереть быстрее, чем многие думают.
@Yukiteru 3 декабря 2014 8:49
Я не боюсь этого, г-н Линус не собирается удалять параметры по умолчанию из одной версии в другую, он поставит новую систему как НОВУЮ и позволит вам выбирать между обычной и новой.
Что касается части пользовательского пространства, вы можете создать пакет, который делает это независимо, если systemd делает это, почему еще 50 не могут сделать это? Более того, разные способы сделать это заставят разные терминалы по-разному использовать все с помощью USE активировать и деактивировать, как мы привыкли.
То же самое и с kdbus, что Линус допускает это в 3.19, как он говорит, это не означает, что нужно будет активировать его «да» или «да».
Я очень доволен openbox + compton, рабочие столы для меня могут исчезать, потому что они не повлияют на меня ни в малейшей степени.
@ anonymous вопрос в том, что удаление CONFIG_VT - это то, что в конечном итоге будет полным (из того, что я прочитал), то есть в ядре останутся только примитивы, в то время как остальные инструменты будут в пользовательском пространстве, это неплохо, напротив, он удалит много старого кода из ядра, упростит его обслуживание и станет гораздо более настраиваемым (полная поддержка KMS / DRM для консоли). Конечно, вначале будут обе системы, но в долгосрочной перспективе (15-20 выпусков) он может выйти из ядра, или даже раньше многие инструменты больше не поддерживают такой код в пользу более нового и лучше поддерживаемого кода.
Теперь вы говорите, что если systemd это делает, потому что еще 50 не могут этого сделать (я полагаю, что еще 50 приложений). Что ж, если мы увидим сильные зависимости KMSCon (самый старый проект в этом смысле), они будут libudev (код, который скоро будет присоединен к systemd, не будет поддерживаться и будет конфликтовать с systemd, если он работает сам по себе), libdrm, libxkbcommon, libtsm и сам systemd для работы с несколькими местами, поэтому, когда вы это видите, вы понимаете, как все складывается, принимая для себя множество инструментов, необходимых для работы ОС GNU / Linux без проблем.
@Yukiteru 3 декабря 2014 9:46
Здесь, в gentoo libudev - это виртуальный указатель на sys-fs / eudev, поэтому специалисты gentoo позаботятся об изменении eudev в соответствии с API, продиктованным новой системой ядра.
Поэтому я думаю, что дистрибутивы, отличные от systemd (привет, девуан), будут использовать if или if eudev.
То, что произошло с оригинальным udev, должно произойти, systemd поглотил его, но здесь ядро - это то, что продиктовано API для взаимодействия с консолями с использованием DRM / KMS ... Я уже хотел увидеть urxvt, использующий это ... хе-хе
Я согласен с тем, что тот, кто использует systemd, не будет иметь возможности что-либо изменить ... полное и жесткое наложение и, как я уже сказал ранее ... плакать на кладбище.
@ anonymous, конечно же, то, что вы говорите, является другой возможностью, eudev проявит больше сил в этом отношении и сохранит возможности выбора различных инструментов.
PS: Как вы говорите, было бы интересно посмотреть, как виртуальные машины используют преимущества KMS / DRM вместе с fbdev 😀
Вы в точности повторили концепцию, которую я критиковал, потому что я никогда не говорил о системе, я говорил о связи между процессами, и я повторяю еще раз, откуда вы это берете, потому что два процесса взаимодействуют, смерть одного подразумевает, что у другого есть широкие возможности умереть? Объясните мне, как два процесса, находящиеся в разных областях памяти, могут взаимно влиять на внутреннее поведение друг друга. Давайте посмотрим, объясню ли я себя, с точки зрения одного из этих процессов, он обращается только к механизму IPC (независимо от того, что было определено для связи с процессами systemd). Если программист так плохо умел не включать код, который может иметь дело с неожиданным вводом и выводом, это что-то еще, но это не имеет ничего общего с тем, что один процесс влияет на внутреннее устройство другого. Если происходит сбой systemd-networkd, он не должен убивать journald или systemd, как в старом sysvinit, тот факт, что сбои inetd не должны влиять на него, это отдельные процессы.
@dariem просто объяснил, поняли ли вы идею:
То, что вы говорите, безусловно, является поведением, которое всегда ожидается от модульных программ и процессов. Модульность была реализована для этой цели, для разделения двух процессов, чтобы они занимали свои собственные пространства памяти и чтобы они взаимодействовали каким-либо образом (IPC и т. Д.), Так что в случае, если что-то пойдет не так, ничего плохого не произойдет. И система может продолжать работать без перебоев. Теория, которая, безусловно, получила большую поддержку благодаря своему потенциалу и огромному запасу надежности, который она придает современным вычислениям. Это не всегда верно (жизнь не всегда прекрасна), и я думаю, что вы наверняка были жертвой этих событий в том или ином случае (это, безусловно, касается всех, независимо от ОС, которую вы используете), и я дам пара примеров.
Первый связан с Xorg (который представляет собой модульный процесс, такой же, как systemd), который иногда сходит с ума от драйвера и просто дает сбой и оставляет вас без графики, в то время как остальная часть системы продолжает работать, как ожидалось (Благословенная модульность 😀). Пока все хорошо, наша теория о том, что модульные процессы не должны нарушать работу системы, работает нормально. Но (всегда есть некоторые но) иногда Xorg дает нечто большее, чем безумие, и по какой-то странной причине (которая может варьироваться от управления мышью до графического драйвера) не только вызывает сбой Xorg, но также дает вам самую красивую панику ядра ( и граффити на мониторе, как у Пикассо), которые вы можете себе представить, а затем вы понимаете, что независимо от того, насколько он модульный, если процесс взаимодействует и обменивается информацией / данными с другим, и что-то идет не так в одном из них, и для по какой-то причине ошибка не может быть обработана правильно, шансы затронуть рассматриваемые процессы возрастают из-за того простого факта, что данные неверны или просто повреждены, и тогда наступает катастрофа.
Если вы думаете, что этого не может произойти, я оставляю вам несколько отчетов об ошибках (один мой в Debian и имеет несколько фотографий) старой ошибки, которая есть в Xorg, mesa, nouveau и драйвере ядра drm / kms, которая, несмотря на работающие ** по отдельности и модульные **, вместе они не очень хорошо уживаются, по крайней мере, в данных обстоятельствах.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742930
https://bugzilla.redhat.com/show_bug.cgi?id=901816
https://bugzilla.redhat.com/show_bug.cgi?id=679619
А теперь другой пример с systemd. У нашего старого Sysvinit была особенность, заключающаяся в том, что, несмотря на то, что он старый, он был очень надежным, вплоть до того, что если в вашем / etc / fstab была запись о разделе (не важна для системы, понимайте / mnt / Disk160GB), и это было бы невозможно. Чтобы не монтироваться по какой-либо причине, монтирование было просто пропущено, выдано предупреждающее сообщение и процесс загрузки продолжился. Другое дело, systemd, несмотря на его модульность, если у вас есть запись в / etc / fstab, а systemd по какой-то причине видит, что его невозможно смонтировать, он не только ждет, пока раздел станет доступным (нормальное запрограммированное поведение ) для его сборки, но если время истекает, ваша система останавливается, и вы ничего не можете сделать, кроме как войти в режим восстановления и удалить эту строку из / etc / fstab, что-то на самом деле не работает. Этой маленькой детали больше нет во время автоматического монтирования при загрузке, и весь процесс останавливается, сначала (systemd-) эта маленькая деталь была уродливее, потому что дамп только что появился, и вам пришлось перезапустить. Кто-то, изучивший детали, скажет вам.
Другой пример, который я могу привести, - это coredumpd в systemd. coredumpd по умолчанию передает всю свою информацию в journald, чтобы последний записал захваченную информацию на диск. Пока все хорошо, мы используем модульность systemd в наших интересах. Но это иногда случается, когда coredump очень большие, настолько большие, что они могут занимать несколько ГБ, и в процессе передачи информации из coredump в journald, а затем на диск, происходят странные вещи, например, Xorg перестает работать и даже ядро паника. Конечно, это происходит не только с systemd, но и из-за того, как он спроектирован, увеличивает коэффициент сбоев и создает другие неприятные детали (среди них повышенное потребление памяти, повреждение журнала, неполные дампы), которым приходилось работать с ядром KDE, у вас есть наверняка прошли через несколько подобных эпизодов, и вы поймете важность наличия опции синхронизации в / etc / fstab для вашего раздела с дампом, и вам наверняка не понравится тот факт, что вы не можете использовать какой-либо другой вариант для обработки дампов, если у вас установлен systemd. Пример того, что может случиться с systemd-coredumpd.
https://bugs.archlinux.org/task/41728
Теперь, чтобы закончить:
Разве они не должны быть модульными программами и процессами? Да, они модульные. Ядро - единственная монолитная вещь, о которой я здесь говорил, но оно также принимает модули (LKM), так что это будет своего рода гибридное ядро, хотя его базовая форма дизайна не предназначена для этого типа структуры, и это делает его немного нестабилен при определенных обстоятельствах.
Эта модульность не должна позволять мне уберечь мои процессы и систему от сбоя, если что-то пойдет не так? Это правда, модульность - это мера, разработанная для достижения высокой степени стабильности и надежности, но это не стопроцентно безошибочная мера, потому что, если что-то может пойти не так, это просто пойдет не так, независимо от того, насколько модульным является реальность.
Какой systemd должен контролировать все, чтобы можно было использовать контрольные группы и другие параметры, добавленные в ядро? Совершенно неверно. В этом нет необходимости, systemd можно было бы оставить с интерфейсом для управления запуском и назначением контрольных групп процессам и демонам, которые будут в системе, без необходимости брать на себя количество сервисов, которые у него сейчас есть, и лучший пример этого; что OpenRC также может использовать контрольные группы и не по этой причине вторгается для выполнения этой задачи.
Чего я предвзято и боюсь, когда говорю о systemd? Я понятия не имею, откуда он это взял, потому что, как вы видите мой ответ, я не боюсь этого, я говорю только о тех аспектах, которые мне не нравятся в systemd, и уже не полагаясь на мнение третьих сторон.
Наконец, вы говорите: «Если бы программист так плохо умел не включать код, который может иметь дело с неожиданным вводом и выводом, это что-то еще ...»
Конечно, сказать, что программист из-за того, что не включил код, который обрабатывает ВСЕ возможные способы, которыми его программа может быть взломана из-за некоторого ошибочного ввода данных, ПЛОХО, это кажется мне возмутительным. Каким бы хорошим программистом ни был человек, неспособный разработать безошибочную и безотказную программу, ВСЕГДА будет сбой, который так или иначе обнаружится, а когда это произойдет, это будет благодаря случайному сбой во время его использования хакером или взломщиком, эксплуатирующим уязвимость, путем анализа и аудита кода или любыми другими средствами, на которые программист может положиться. Лучше померить слова, прежде чем говорить что-то подобное.
Привет.
Пример Xorg, который вы приводите, является наименее подходящим, поскольку каждый, кто прошел переход на KMS / DRM, знает, что проблема вызвана ошибками в модулях ядра для управления KMS, которые предоставляются разработчиками драйверов Xorg. Ошибка в модуле KMS аналогична панике ядра, она не имеет ничего общего с обменом данными между процессами, потому что в этом случае Xorg выполняет системный вызов (syscall), чтобы ядро меняло режим экрана, то есть задействован только один процесс (Xorg), вызывающий ядро, не имеющий отношения к тому, с чем мы здесь имеем дело.
Текущее поведение systemd, когда не удается найти точку монтирования, не имеет значения, независимо от того, что это функция, которая кому-то может не понравиться, и которая решается путем запроса поддержки другого поведения, а именно игнорирования неудачного монтирования. Дамп ядра, который произошел раньше, мог быть вызван разными причинами, о которых можно было только догадываться, но тот факт, что выполнение не было продолжено, может быть из-за желаемого поведения, поскольку вы говорите, что его нужно было перезапустить, а не то, что было ядро паника или автоматический перезапуск. Поскольку я не прошел через это, я не могу высказать свое мнение.
Что касается проблемы, которую вы поставили с помощью systemd-coredumpd, и ссылки на отчет об ошибке, все указывает на то, что эта проблема в Arch Linux была из-за сжатия, которое они включили systemd, когда они скомпилировали его для этого дистрибутива. Это больше похоже на проблему с алгоритмом сжатия, чем с самой системой. Операционная система не дает сбоев, скорее, алгоритм сжатия, используемый для хранения файлов coredump, похоже, истощает систему, и это вина разработчиков Arch Linux, которые скомпилировали systemd. Однако в systemd есть настройки для ограничения потребления ресурсов и включения / выключения захвата всех coredump, сообщаемых ядром. Может быть, разработчикам Arch Systemd и тем, кто использует KDE, стоит взглянуть на них.
Вы говорите, что OpenRC также использует контрольные группы, не будучи агрессивным. Проблема заключается в следующем: как OpenRC распознает имя исполняемых файлов демона, чтобы точно знать, какое распределение ресурсов является наиболее подходящим? Я не совсем уверен, является ли это одной из причин, по которой systemd заботится о стольких вещах, давая исполняемым файлам хорошо известное имя, но я подозреваю, что дело обстоит именно так. Кроме того, он устраняет необходимость иметь тире посередине для запуска каждой из этих служб, напрямую вызывая исполняемые файлы.
Я не стану отрицать, что в systemd может быть много ошибок, но, исходя из этого, я так не думаю, чтобы связать их все с тем, как он задуман. В случае с sysvinit это была супер стабильная, зрелая программа, systemd только начинается.
https://www.reddit.com/r/LinuxActionShow/comments/2nv4hp/ask_lennart_poettering_a_question/
Как они лопают шары с помощью systemD, xD Если вам это так не нравится, создайте свой собственный дистрибутив, для чего и предназначены бесплатные программы é_é
Дело не в ненависти, а в защите своего сообщества.
Кстати если есть раздачи Самостоятельное «подполье»:
http://gutl.jovenclub.cu/neonatox-un-linux-iconoclasta
Уважает
потому что сравните все с microsoft, что он ведет себя как окна ... если все работает хорошо, и это связано с развитием и развитием Linux, в чем проблема ... каждый проект в начале может иметь ошибки изменений, если программное обеспечение и т. д. были идеальными, Мы люди, но поэтому у нас есть ошибки.
что если systemd выйдет из строя, система выйдет из строя ... и если ядро, xorg, grub выйдет из строя ... есть люди, которые, обновляя ядро на своем компьютере или ноутбуке, потеряют систему ... тогда из-за настойчивости совершенство чего-то ...
как если бы какая-то система, которая вышла, не имела ошибок, ошибок или чего-то в ее начале или даже уже в ее зрелости были сбои
Systemd был введен как стандарт с грязной игрой, это обязательная зависимость для многих пакетов, потому что многие программы были поглощены systemd либо потому, что они поддерживали их, либо потому, что они медленно удаляли их, поскольку они больше не были актуальны, потому что systemd уже предоставил что-то подобное.
Это ограничивает свободу выбора, то есть дистрибутивы не могут выбрать НЕ использовать systemd, они могут попытаться сопротивляться, как gentoo, но это скорее временное решение для systemd, openrc - это просто поддерживаемый sysv сервис-менеджер для init и initscripts дистрибутива. , systemd предоставляет больше функциональных возможностей, чем openrc, и каждый день добавляет новые функции. Новое программное обеспечение поддерживает systemd и требует реализации чего-то подобного, что в конечном итоге делает другие init более сложными и более похожими на systemd, чего вам не нужно.
Systemd делает много вещей по сравнению со старым init, который просто считывает пару строк из / etc / inittab, а затем загружает каждый из сценариев инициализации и их конфигурации в соответствии с уровнем запуска. Старый подход был намного проще и независимее. Мы находимся на этапе перехода к новой эре однородности, решения нет, его невозможно остановить.
Через несколько лет практически не будет разницы между использованием debian, использованием Arch или Fedora, идентичность каждого дистрибутива будет потеряна, если мы продолжим так, и systemd будет становиться все более навязчивым с каждым днем, что даже станет частью имени системы (systemd / gnu / linux)
LOL
Взывать к церкви>: D
Что говорит Дон КЗКГ, оставляю вам вот что: https://blog.desdelinux.net/systemd-vs-inteligencia/#comment-127648
Проблема в том, что вы аргентинец (я тоже), но способ самовыражения, который есть у большинства аргентинских linuxeros, о которых я читал, действительно беспокоит, хотя также говорят, что мир свободных программ привлекает определенных людей. Я спасаю то, что вы не претендуете на роль аргентинца, но, к сожалению, показывает лиги.
уйюйы .. тот мальчик упал с тяжелой артиллерии ..
сильный комментарий !!
Жужу .. ..почоклос .. xD
Из этой статьи следует, что все, что они делают, это «навязывают» систему. Я вхожу не для того, чтобы оценить, лучше (а это не так) или хуже. Я говорю, повторяю, подчеркиваю и подчеркиваю, что я действительно не хочу, чтобы мне что-то навязывали.
Такие фразы, как: «Мы просто не используем их для процесса загрузки, потому что мы думаем, что они не лучший инструмент для этой конкретной цели».
И кто ты такой, чтобы говорить мне, хочу ли я использовать тот или иной инструмент?
Есть каждый. Я просто не использую его, точка, и хотя я не могу, я не буду.
Подпись. Талибан.
(Это то, что меня забавляет клоунада)
часто болит голова с этой темой !!!! X_X
Я управлял серверами с помощью Centos 6, а переход на 7 с systemd мне ничего не стоил, не плачьте, жизнь продолжается.
Извините, но я много читаю, что напоминает мне классический дискурс "Windows server - Certified Man VS linux server - OpenSource Man".
1-й - вы увидите, что если вы вынудите ошибку, это нормально, если она потерпит неудачу. Все видео, которые я видел, являются принудительными ошибками. Это как если бы я делаю программу, которая вводит ключевые слова в журнал системного журнала, и в то же время я пытаюсь выполнить сценарий на основе grep для извлечения информации из журнала. ... конечно, он потерпит неудачу, я виноват.
Это все равно, что засыпать сахар в дизель и сказать: «Смотри ... бензин лучше !!!» или, как это делает Windows, неправильно написать файл конфигурации и пожаловаться на то, что демон не начинает говорить «с Windows этого не происходит».
2-й - Этот systemd включает в себя много вещей, которые вы не можете использовать? Ну в чем проблема? Дело в том, что это тот же самый пустой аргумент, который Windows использует против аргументов Linux… «Почему я хочу, чтобы простой текст содержал тысячу и одну опцию, если вы не собираетесь их использовать?»
Я до сих пор слышу, как парни из IBM с их монолитными программами лают о mysql много лет назад, когда читаю кое-что. Я благодарю и приветствую разнообразие GNU / Linux и его сообщества. Если вы дадите мне 50 способов сделать что-либо, я буду выбирать каждый момент тот, который лучше всего подходит для меня или подходит для того, что мне нужно. Вы действительно видите в этом проблему?
3-й - По уровню разговоров я делаю вывод, что у вас есть достаточный уровень, чтобы работать с любым дистрибутивом или настраивать свой собственный и поддерживать его самостоятельно. Почему вы хотите поставить systemd и удалить из него что-нибудь? Разве не проще продолжить работу с init или openRC?
Людям, которые просили меня научить их основам Linux, я всегда говорю одно и то же ... GNU / LINUX - это не WINDOWS, не пытайтесь делать то же самое и не думайте, как если бы это было. Почему вы усваиваете, что sistemd такая же, как initd, или что она работает так же? Разве не легче усвоить работу systemd и использовать ее потенциал, чем пытаться создать такие функции, как init или OpenRC? Это нормально, что тебе это не нравится.
4-й - Что плохого в сложности? Наверняка вы все еще помните, когда вы давали линейное программирование и что наверняка в какой-то момент вы сказали ... «И почему я хочу научиться работать с объектами, если теперь я могу делать все, а еще они позволяют мне использовать переход?» … (Фейспалм через пару месяцев отличный, если xD)
Давайте проясним. Текущий init (и я включаю systemd) имеет много недостатков, которые можно устранить, только добавив сложности. Другого нет, поскольку для роста взаимосвязанной системы она должна усложняться, рискуя иметь слабую часть, но это лучше, чем оставаться в застое.
Это долгий путь, и если… sistemd не решит все проблемы. Но ни один из них не остается с SysVinit.
PS: Обратите внимание на иронию в том, что я использовал компьютер моего коллеги «Я цепляюсь за Windows-Server Defender», чтобы он, кстати, мог это прочитать. xD
Одно дело защитникам других ИНИЦ, дающих технические данные и ссылки… ЧАПО !!! Мне нравится видеть подобные аргументы и данные. Обратите внимание: данные за октябрь 2014 г. носят исключительно исторический характер.
Многие вещи, о которых идет речь, уже исправлены, и многие тестовые площадки, опубликованные в 2013 году, уже проверены.
@роло
Если это правда, если вы видели видео, которое вы НЕ сделали, вы увидите, что размер журнала составляет 8 МБ, ничего больше и так далее, и все будет повреждено, кстати, вы можете отправить вывод journald в syslog в простом виде текст? Да, но даже в этом случае, если вы коснетесь журналов, созданных journald, это произойдет, система зависнет и, понятно, давайте посмотрим, журнал зависает на PID1 вместе с такими сложными вещами, как systemd, он не работает, вы видите, что это не так. имеют некоторую часть кода, которая не позволяет редактировать что-либо, кроме того же PID журнала, а также не имеет возможности продолжать запись после того, как журнал поврежден, что показывает, что в дополнение к мышлению в режиме Windows LP является плохой программист.
Не говорите мне, что это будет только в centos, самой стабильной версии дистрибутива, использующей systemd, клон RHEL7, и я не сообщаю и не планирую сообщать об ошибке.
Правда в том, что чем больше я читаю комментарии pro systemd, я понимаю, что они действительно похожи на религию, или вы поддерживаете, или вы враг, но из этих религий типа ИГИЛ, религий исламского государства, полностью На самом деле экстремисты, я знаю по опыту, любители системы, они так думают, или вы с ними, или вы враг. Это то, что Леннарт продвигает с его высокомерием, и, пожалуйста, не трахайте меня с Линусом, поддерживающим его, systemd не было этим, ЭТО НЕ БЫЛО, я использовал systemd, как только он вышел в Fedora 15, и это был просто более быстрый запуск, он не заменил модульность GNU / Linux.
Если я убью rsyslog, повреждаю его журналы или заменяю его чертежом, ничего больше, только то, что у меня закончился журнал, ничего не зависает, система не пострадает.
@ Рафаэль Мардожай
Это то, что делает Devuan, это то, что сделали Void Linux и другие, кто держится подальше от systemd.
@Юкитеру
Конечно, вас никто не читает, как мне говорят Талибан, они не читают вас, потому что вы используете окна или вы комментируете их, и потому что я считаю, что немногие из любителей systemd понимают техническую часть того, что вы говорите, и в этом заключается проблема.
======
По правде говоря, я все еще думаю, что человек, известный еще в 2006 году, был в чем-то прав:
«Я не хочу, чтобы люди использовали Linux или знали об этом, у этих ребят из Ubuntu мои яйца полны»
Я- "Почему?"
«Когда что-то становится известным и для масс, это гадит, это лажает, и образцов этого есть в изобилии»
Я- "как что?"
«Посмотрите, что случилось с Debian, теперь у него есть глупый сын по имени Ubuntu, и помните, что через несколько лет у нас будут« хакеры »и« вундеркинды », которые сосали Ubuntu, и они не будут знать, как отличить Ext3 от NTFS»
Что-то было правильным…. systemd побеждает тех, кто знает, как говорит Аллан Макрей, потому что ему все равно, как он запускает свою машину, для него это кнопка, магия, и у меня есть подсказка. Среди тех, кто заинтересован только в "работе" с хорошими функциями, в общем, для сервера на самом деле используют LFS, Gentoo или BSD, а также те, кому это нравится, потому что он быстрее включается на их ПК с цветными огнями, красивыми звуками и азартными играми, но они не знают, что такое системный вызов.
@SynFlag, если они не читают, это по их собственному решению, что касается ОС, которую я использую, если я на работе и комментирую с ПК с Windows, это потому, что это единственное, что у меня есть под рукой, кроме сервера это в Debian Wheezy и, очевидно, с сервера, я не могу здесь комментировать.
Даже дома я был вынужден использовать компьютер моей сестры, потому что мой компьютер умер (MB и источник питания сговорились против меня), и даже в этом случае, когда у меня есть время, я устанавливаю LiveCD и использую Sabayon (с OpenRC), чтобы комментировать здесь, как я делаю так же, как пишу эти слова.
Теперь, если они скажут мне или думают, что я антисистемный Талибан, для меня это не имеет значения. Как я уже сказал, я использовал systemd и знаю, что нога хромает, не только это, я обычно много читаю список systemd, чтобы узнать о вещах, которые появляются в новых версиях, а также знать об изменениях, которые сделаны и обсуждений, которые там проходят. Теперь, если какой-либо любитель systemd понимает технический аспект того, о чем я говорю, и я вставляю свои ссылки (в основном ссылки на репозиторий systemd git), и даже тогда не может видеть реальность, это только позволяет мне думать, что я продаю это в их глазах и экстремизм в их способах видения / мышления / чувств / любви / прославления / восхваления / поклонения systemd настолько велик, что не имеет значения, если даже сам Линус выбьет ***** **** из systemd, они будут до сих пор твердо придерживаются мнения, что они правы.
Здравствуйте! Я не очень разбираюсь в этом и хотел бы знать, для чего нужен этот "systemd" и почему о нем так много говорят, в чем проблема и какая альтернатива есть? благодаря
Комментарий SynFlag! Я от «гиков», «гиков» и «про линуксеров» до тех же самых.
И это будущее, которое нас ждет; Убунту даже в супе; Ноутбуки с Linux, чтобы просто получить доступ к Steam и сыграть в последнюю популярную игру. И легионы маленьких вундеркиндов, которые не знают, что это за капсула.
Постскриптум: концепция фона systemd - отстой.
кнопки adk и forum не видны на главной странице
Итак, согласно @SynFlag, теперь все, кто не настроен против системы, - это n00b, экстремистский религиозный фанатик и чума, которая развращает GNU / Linux. С таким узким мнением, я не знаю, стоит ли обсуждать эту тему. Лучше дать воде стечь, и в конечном итоге произойдет то, что должно произойти.
Это правда, наступает момент, о котором больше нельзя говорить. только время покажет нам, будет ли sytemd чем-то положительным для мира свободных программ или нет.
Это также натолкнуло меня на мысль, что если этот дистрибутив на основе debian, который не будет использовать systemd, будет реализован, он поможет успокоить дух тех, кто не хочет ничего знать о systemd.
как когда появился gnome 3 и возникло огромное сопротивление, пока не появилась "вилка" корицы и единства, позволяющие продолжать использовать приложения gnome на рабочем столе с большим количеством конфигураций и дизайном, больше продуманным для ПК, а не столько для прикосновения
Возможно, это, Роло (появление Девуана), может стать предметом консенсуса. Я думаю, что нам всем нужно, чтобы он содержал поляризованную и воинственную атмосферу обсуждения. Девуан будет пространством для создания и продолжения образа действий, и это поможет успокоить духи. Процесс, который мы пережили в Debian, был болезненным, однако мы должны столкнуться с ситуацией, у нас нет другого выбора, кроме как принять разделение. Это немного похоже на развод. Эта вилка может быть стенограммой мирного договора и точкой и частью. Конечно, были альтернативы, Slackware, Gentoo, Funtoo, Crux, PCLinux OS, теперь Manjaro (и это лишь некоторые из них) ... но сцена «deb» требовала альтернативы без systemd. Кажется очевидным, что никто никого не собирается убеждать, аргументы уже есть, и консенсуса нет (несмотря на то, что у systemd есть хорошие идеи и опасности, которые несет в себе это программное обеспечение, очевидны). Пришло время форков и свободы для пользователя (ведь речь идет о свободном программном обеспечении, верно?).
Одним из факторов, влияющих на процесс, было чувство «разочарования» со стороны некоторых из нас, которые доверяют Debian. Вот почему Devuan представлен как вилка, а не как производная. Напряжение возникает, потому что то, что произошло, никому не нравится; ни pro-systemd (отсюда некоторые яростные атаки, пытающиеся опорочить), ни anti-systemd (которые сделали ставку на вилку). В среде стоит вопрос «сколько талантов мы можем потерять?», Как с одной стороны, так и с другой.
Все пользователи Debian смотрят на дистрибутив определенным образом (это может быть применено и к другим дистрибутивам). Одни восхищаются его техническим качеством, другие - его общественным договором, его влиянием в мире Linux, уважением, которое он заслужил за эти годы, его стабильностью в критических производственных средах ... У некоторых пользователей это восприятие изменилось, появилось разочарование. . Разочарование, разочарование, называйте это как хотите. Оттуда к разделению всего лишь маленький шаг.
Развод Debian аналогичен тому, что произошло с NetBSD и OpenBSD. Хотя время покажет. Я вижу много ожиданий от форка, и это заставляет меня думать, что это не будет мимолетным и бесплодным распределением. Как раз сегодня член команды гномов комментировал список рассылки Девуана (хотя он и делал это неловко), это, на мой взгляд, предполагает, что Девуан вызывает интерес и хочет каким-то образом диалога.
В любом случае, хороших выходных.
@роло
Сказать, что видео может быть обманутым или программное обеспечение - полная ошибка и оскорбление, в моей жизни PU ** я обманул что-то, чтобы создать миф, никогда, я не хвастаюсь тем, что видел эту неудачу своими средствами, а не своими уловками. Все они идут на *****, а не на *****, и я не собираюсь вдаваться в подробности дебатов о systemd, потому что это совершенно бесполезно, никто ничего не хочет понимать, и все это похоже на регресс, который, Ненавижу, потому что все это по догмату веры. Будьте довольны systemd.
@SynFlag насилие врет
Это видео действительно демонстрирует ложность утверждения о том, что если один из модулей systemd разрушен, это вызывает сбой systemd, поскольку, очевидно, из того, что показывает ваше видео, этого не произошло, xddddd и, кстати, журнал запускается от имени пользователя root, поэтому, если третья сторона входит и злонамеренно испортит двоичный файл журнала, я бы не стал беспокоиться о systemd, а скорее о безопасности вашего компьютера. xdddddd. Наконец, что касается видео, воспроизведите то, что показано, отредактировав с помощью nano файл /var/log/journal/24f02f5b2b16758b820ea6a751ed6efb/system.journal, и при перезапуске вы обнаружите, что есть новый system.journal и system @@ 24f02f5b2b16758 @@ 820f6f751bXNUMXbXNUMX. Journal, который является поврежденным двоичным файлом.
То есть журнал понимает, что файл поврежден, поэтому не переименовывает его и снова создает новый, я не вижу, в чем проблема? То же, как если бы файл system.journal был удален, journal возвращает его для создания.
Интересно, что бы случилось, если бы я испортил файл журнала с обычным текстом с помощью шестнадцатеричного редактора, конечно, пока не поймете, что файл был поврежден, все данные будут уничтожены Oo
Давайте поговорим немного о журнале, который является одной из наиболее частых критических замечаний в отношении systemd.
journal - очень важный компонент systemd, который фиксирует сообщения системного журнала, сообщения журнала ядра, сообщения ОЗУ и начальной загрузки, а также сообщения, написанные в STDOUT / TDERR, и делает всю эту информацию доступной для пользователя.
Но самое главное, журнал можно использовать параллельно или вместо традиционного демона syslog, такого как rsyslog или syslog-ng, поэтому осторожный системный администратор может использовать rsyslog или syslog-ng в качестве второго инструмента запроса, помимо преобразования записей журнала. в обычный текст на случай повреждения двоичного файла
Еще один важный факт о журнале заключается в том, что если папка / var / log / journal не создается, информация сохраняется только временно, которая теряется при каждом перезапуске.
например, когда я ввел systemd в debian, сохранение журнала не было активным, поэтому мне пришлось вручную создать папку журнала
http://0pointer.net/blog/projects/journalctl.html
Те, кто владеет английским, не могут пропустить переговоры, которые проходят между разработчиками devuan, jaromil dimkr max2344 и другими на IRC-канале freenode #devuan.
Большое удовольствие читать исследования кода systemd, поскольку они специально распространили его, чтобы заразить (создать ненужные зависимости).
Systemd меня раздражает ... прямо ... это сложно. Небольшая документация или гребаный тонкий работает только с KDM или gdm, а в легкой системе я хочу, чтобы тонкий lxdm не поддерживал его и не компилировал его… .. Серьезно, даже раньше… Я был доволен, что они должны. По правде говоря, я начал использовать openrc, как говорят в gentoo, и это помогло…. Много
@роло
Вы - наглый и новостной злоумышленник, чтобы сказать это. Это худшее оскорбление, когда вы говорите мне, что я лгу или фальсифицирую данные, мне действительно противно, как, чтобы защитить что-то, вы нападаете на людей, которые занимаются серьезной PoC, как я. Журнал поврежден, система вылетает, перезапуск службы не работает, поэтому нет другого выбора, кроме как перезапустить машину, что не лучший вариант для взломанного сервера, вы собираетесь сказать мне, что если безопасность была скомпрометирована, Лучше всего перезапустить или переустановить, и это единственное, о чем я должен беспокоиться, поскольку systemd говорит, извинившись, и не выполняет горячий анализ ЧТО ПРОИЗОШЛО? чтобы добраться до этой точки? Очевидно, вы являетесь еще одним продуктом нового системного администратора, если вы дойдете до того, что было создано с помощью ubuntu и имеет безопасность DOS 5.0 на вашем компьютере, поэтому то, что вы говорите, я принимаю как то, от кого это исходит, меня беспокоит, что вы также сомневаюсь. Тот, кто фальсифицирует, это вы, ответили ли вы той же ОС обновлениями ТОГО дня? Конечно, нет, поэтому попробуйте солгать другому. Какая у вас нехватка возможностей, иди поработай таксистом на большее, чем это, я сомневаюсь, что это даст тебе, перестань играть с linux и продолжай искать pr0n
Давайте посмотрим на голубя (синфлаг), папа покажет вам, как заставить журнал продолжать работу после того, как по какой-то причине наш двоичный файл журнала журнала поврежден, без необходимости перезагружать компьютер.
В этом примере мы начинаем с базовой установки debian 8 jessie.
По умолчанию systemd-journal.service поставляется с функцией storage = auto, поэтому, чтобы иметь постоянную запись журналов, необходимо предварительно создать файл в / var / log / journal /.
# mkdir -p / var / log / journal /
Чтобы журнал начал вести журналы, вам НЕ нужно перезагружать компьютер, просто выполните:
# systemctl перезагрузить systemd-journal.service
o
# systemctl принудительно перезагрузить systemd-journal.service
### теперь мы собираемся смоделировать, что двоичный журнал журнала поврежден ###
# cd / var / log / journal
# лс
24f02f5b2b19808b820ea0a980ed6efb
# cd 24f02f5b2b19808b820ea0a980ed6efb
# наносистема.журнал
### теперь модифицируем какую-то строку файла, чтобы имитировать, что он поврежден
# журналctl
### как и ожидалось, ничего не происходит
#### нужно ли перезапускать компьютер, чтобы журнал создал новый двоичный файл? Нет
# systemctl принудительно перезагрузить systemd-journal.service
# лс
system@24f02f5b2b19808b820ea0a980ed6efb-0000000000000001-0005069a53abf581.journal
system.journal
# журналctl
### Как мы видим, journal создает новый двоичный файл журнала, и теперь мы можем снова получить доступ к информации, не перезагружая компьютер в любое время.
https://www.youtube.com/watch?v=hEagyMdkN4A&feature=youtu.be
вывод: синфлаг или ты невежественен, или ты басня
этот конечный лол
для ошибки ввода и злоупотребления копированием и вставкой я написал systemd-journal.service, когда на самом деле служба называется systemd-journald.service
Пишон?, ... как ты худой, серьезно .. Я уже знал это, сообщите об ошибке в красной шляпе, чтобы узнать, что они сказали, я найду ответ, посмотрю, поймаете ли вы:
Если вы удалите выходной файл или перезапишите его части, демон не сможет ничего с этим поделать: если у злоумышленника есть разрешения на изменение выходного файла, он уже победил. Демон мог бы проверить некоторые из этих вещей, но это было бы неэффективно и ни для чего не пригодилось. Если вы хотите, вы можете настроить периодическую криптографическую подпись с помощью journalctl –setup-keys. См. Справочную страницу journalctl.
Journalctl зависит от rsyslog, он не перезапускается в случае ошибки в журнале, который не нужен rsyslog, итого, вы должны использовать fordward для отправки rsyslog, и таким образом он записывается, несмотря на все, и журнал журнала создается повторно, это недостаток дизайна journald, если ты не хочешь этого замечать, убей меня.
@роло
На видео (я не знаю, сделали ли вы это) я вижу, что в минуту 2:11 используется ls, а не ls -l, что позволило бы увидеть размер, который изначально имел файл system.journal, затем они его редактируют с помощью nano и добавьте пустые строки, перезапустите службу вручную, и в минуту 3:15 они снова сделают ls, а не ls -l, затем на минуте 3:20 они увидят журнал с journalctl, это показывает текущий журнал, который в порядке.
А теперь мои вопросы:
1 - поскольку используется ls, а не ls -l, чтобы можно было увидеть исходный размер журнала до редактирования
2 - что случилось со старым журналом? куда systemd поместил это в коррумпированный двоичный журнал?
3 - с помощью какой команды systemd вы можете восстановить поврежденный двоичный журнал ... который вы не должны удалять
привет
@ анонимный
А теперь мои вопросы:
1 - поскольку используется ls, а не ls -l, чтобы можно было увидеть исходный размер журнала до редактирования
2 - что случилось со старым журналом? куда systemd поместил это в коррумпированный двоичный журнал?
3 - с помощью какой команды systemd вы можете восстановить поврежденный двоичный журнал ... который вы не должны удалять
1 правда, я не думал об этом, просто используйте ls, чтобы увидеть, какие файлы были в каталоге, но если вам интересно, вы можете реплицировать его, процедура подробно описана, и я сделал это в виртуальном боксе (установка базы debian - это немного беспорядок)
2 старый журнал остается в той же директории, только systemd переименовывает его кучей цифр и букв (показано на видео)
3 В любом случае вы можете попробовать использовать сторонние приложения (я полагаю, какой-нибудь шестнадцатеричный редактор), поскольку, если systemd сможет восстановить поврежденный файл, он не переименует его и не создаст новый. В любом случае, и как я уже упоминал в других случаях в этом посте, осторожный системный администратор может использовать rsyslog или syslog-ng в качестве второго инструмента запросов, помимо преобразования записей журнала в простой текст в случае повреждения двоичного файла.
Я имею в виду, это не идея убедить кого-либо использовать systemd (мне бы даже понравилось, что в установщике debian есть возможность выбрать int). но я не собираюсь молчать, когда читаю невежественных или сказочных людей, которые продолжают повторять ложь о systemd, поскольку блог существует, когда видишь, что эти высказывания не совпадают с реальностью. и как сказал Аристотель, единственная правда - это реальность 😉
@роло
Я посмотрел видео еще раз, и да, он был там указан, только числовое имя было таким длинным, что я его увидел, я подумал, что это каталог… Суверенное имя.
Что касается восстановления двоичного файла, да, это логично, что вы говорите ... если бы я мог его восстановить, я бы не создавал новый.
Наконец, я утверждаю, что это не должен быть двоичный файл, чтобы этого не произошло, и чтобы его можно было увидеть без специальных инструментов с journalctl ... Я до сих пор не понимаю, что заставило его использовать двоичный формат.
Приветствую и спасибо за ответ
Роло, посвятите себя другому:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393
Я знал это, не зная того… Как вы замечаете разницу между тем, кто что-то пробует, и тем, кто делает только пердящие видео
Я подхожу к закрытию ocote de Rolo, ошибка, обнаруженная в моем PoC, была сообщена, поэтому закройте ocote pichon:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393
Посмотрим сказочное:
1 Вы заявили, что для решения проблемы в журнале необходимо перезагрузить компьютер, как в Windows ПОЛНОСТЬЮ ЛОЖНО
Я показал вам, что это ложь, и в видео, которое вы никогда не использовали, вы используете команду systemctl force-reload systemd-journald.service, потому что, если бы вы использовали ее, ваш аргумент вылетел бы из строя (или вы не знали команду , что будет показывать, что вы невежественны, или намеренно не использовали его, что показало бы, что вы рассказчик)
2 Вы говорите, что есть отчеты об ошибках, с одной стороны, это совершенно неуместно, так как обычно люди сообщают о большом количестве ерунды как об ошибке (чтобы вы понимали, что не каждый отчет об ошибке является настоящей ошибкой), это даже дает мне представление, что вы сам же сообщил. И, с другой стороны, все программы содержат ошибки (сколько сообщений об ошибках имеет sysvinit (программе, которой около 20 лет)), и хорошо в этом отчете то, что он помогает разработчикам обнаруживать и решать проблемы (некоторые быстрее , другие медленнее)
3 Вы говорите, что с ошибкой, которую вы генерируете в журнале, при перезапуске systemd происходит сбой, поскольку на видео вы можете видеть, что вам нужно принудительно перезапустить виртуальный бокс. ПОЛНОСТЬЮ ЛОЖЬ
По правде говоря, systemd не дает сбоев, поскольку система запускается отлично (если бы она не запускала systemd, это вызвало бы панику ядра, и вам пришлось бы войти в режим восстановления)
С вами происходит то, что система проверяется, когда вы пытаетесь редактировать двоичный файл с помощью текстового редактора, и факторов может быть много, таких как выделенная память, состояние операционной системы (на видео система занимает много времени для загрузки и выключения, что говорит о том, что это не чистая установка 0 (что рекомендуется для этого типа случая)) и т. д. Я могу только сказать вам, что двоичный файл, который я редактировал 10 или 20 раз, никогда не проверялся. Это также показывает, что вы либо невежественный, либо рассказчик.
4 Теперь вы говорите, что журнал зависит от rsyslog ПОЛНОСТЬЮ ЛОЖНО, дело в том, что любой может проверить его, установив или удалив rsyslog и увидев, что журнал работает идеально.
Я был бы очень признателен, если вы оставите эту нездоровую одержимость со мной, это не моя вина, что вы невежественны или невероятны
Вывод:
Вы не хотите использовать systemd, я думаю, это здорово, теперь вам не нужно сеять ужас ложью, чтобы привлечь сторонников вашего антисистемного крестового похода. Я жил и давал жить другим, что в мире свободных программ есть место для всех 😉
пояснение по пункту 3, кто-то сказал бы мне, что, поскольку systemd находится в pid1, сбой машины будет означать, что шлем systemd. Две вещи, во-первых, здесь было сказано, что systemd разбился из-за сбоя журнала, но на самом деле есть проверка ввода двоичного файла (который используется в реальном времени) с помощью текстового редактора, я также уточняю, что во всех тесты, которые я проводил, никогда не проверяли виртуальную машину. Во-вторых, никто в здравом уме не может утверждать, что linux не имеет маркировки xddd,
Фаблер?, Худой, сдерживайся немного, фаблер твоя старушка, которая говорит, что я бросаю резину, когда не трогаю ее палкой, возвращаюсь к уважению:
1.- Вам необходимо перезапустить или принудительно перезапустить службу, что не идеально, и в CentOS 7, когда я пытался, перезапуск службы ничего не сделал, не забывайте, что это версия 208, а не новая 217 или 216 Fedora.
2.- Неактуальные и те, кто сообщает об ошибках? ... ты идиот, я тебе даже не отвечаю
3.- UNHAPPY, версия, которую я пробовал в тот день видео, которое вы можете видеть, вылетела вся ОС, почему вы думаете, что орто несчастная ложь? Я не лживая обезьяна, идите брать cindor pajero.
4.- Это зависит от самовосстановления, он не делает этого сам по себе, на самом деле я предложил это разработчикам systemd в качестве функции, чтобы он регенерировал себя без остановки регистрации, если служба не была перезапущена, они приняли это как то, что они должны добавить, так сосать мой член и сказать мне спасибо папа за сотрудничество в то время как я смотрю порно.
Пока худая, я устал разговаривать с обезьянами, для этого я предпочитаю сходить в зоопарк, когда ты на уровне моего ануса болтаем.
@SynFlag Прошу прощения, я не знал, что вы заболели, я действительно думал, что вы невероятный и невежественный, но с тем, что вы только что написали, я понимаю, что вы на самом деле заблуждаетесь.
ну ничего, надеюсь, вы закончите прием лекарств лучше и вернетесь к реальности, сила! вы можете!!!
Я читаю, читаю и перечитываю, но ничего не понимаю, я знаю только, что с тех пор, как вышел Xubuntu 14.04.1, у меня не было проблем с моим ноутбуком или с моим лазерным принтером hp 1102, я не знаю вообще ничего, я пользователь и не знаю, хуже ли systemd или не подходит для init, но повторяю, у меня нет проблем с xubuntu. 🙂
Я читаю, читаю и перечитываю, и я просто знаю, что заново переживаю старую тему. XD