Кожен день наші комп’ютери становлять більш важливу частину нашого життя, якщо у нього є якась проблема, це впливає на наш настрій, наш гумор хе-хе. Звичайно, користувачі Windows більш схильні до панічних атак, ніж якщо віруси (хай живе Linux!), що якщо дефрагментувати жорсткий диск, що якщо шукати та встановити Clean Master для ПК (хоча в Linux нам все ще доведеться чистити систему, BleachBit - одна з найкращих альтернатив). Нещодавно у користувачів Linux (у деяких) виникає певний головний біль, який називається: systemd
Ну до справи, я прочитав цікаву статтю про systemd, що, здається, є те, що було в моді недовго.
SystemD, що здається деяким, як (і я буду використовувати слова друга), одне кільце, щоб керувати ними всіма ... іншим це просто не подобається, або воно з’являється, поки комп’ютер працює нормально, йому байдуже, чи робить init речі X чи Y, чи використовується systemd. Для цього, хто пише, ну ... припустимо, я віддаю перевагу init, я вважаю це простішим 🙂
Я залишаю статтю тут:
Перш ніж почати, я повинен сказати, що мені не подобається рішення змінити ситуацію в Debian, але я жодного разу не збираюся відмовлятися від своєї улюбленої спіралі. Я просто намагаюся, щоби ми збиралися обговорювати тему, принаймні ми робимо її якомога підготовленішою, хоча я сам не вважаю себе просистемним. Для досягнення демістифікації systemd я буду покладатися на веб-сайт, де розробники висловлюють свою точку зору який потрапив до мене в руки колеги, який, здається, є просистемним, хоча він і не є користувачем Debian. Сказавши це, я думаю, що можу перейти до спроби демістифікувати те, що говорять про systemd.
systemd базується на двійковій системі
Можливо, це один із аспектів, який шокує нас найбільше, якщо все базується на двійковій системі, як ми можемо відстежувати те, що зазвичай робимо за допомогою журналів? Я не уявляю, як цей міф народився, але це не зовсім так.
systemd конфігурується майже виключно через текстові файли. Деякі параметри, які також можна змінити за допомогою командного рядка ядра та змінних середовища. У вашій конфігурації немає нічого двійкового (навіть XML). Просто простий, зрозумілий та легкий для читання текстовий файл.
Ця річ монолітна, і вона контролює все
Перш ніж потрапити на згаданий веб-сайт, я зізнаюся, що сам думав так, але, прочитавши те, що говорять його розробники, моя думка щось змінила ...
Якщо ви збираєте systemd з увімкненими всіма параметрами конфігурації, ви будете будувати 69 окремих двійкових файлів. Ці двійкові файли виконують різні завдання і ретельно розділені з ряду причин. Наприклад, systemd був розроблений з урахуванням безпеки, тому більшість демонів працюють із найменшими привілеями (наприклад, використовуючи можливості ядра) і несуть відповідальність лише за дуже конкретні завдання, щоб мінімізувати їхній вплив на безпеку та вплив. Крім того, системні паралелі завантажуються більше, ніж будь-яке попереднє рішення. Ця "розпаралелізація" створюється запуском різні процеси паралельно. Тому видно, що systemd дуже добре розділений на безліч двійкових файлів і, отже, процеси. Насправді, багато з цих двійкових файлів руйнуються настільки добре, що вони дуже корисні поза системою.
Навряд чи можна було назвати пакет, який включав 69 окремих двійкових файлів монолітний. Однак, що відрізняється від попередніх рішень, це те, що ми постачаємо більше компонентів в одному tarball і тримаємо їх у ланцюжку в одному сховищі з уніфікованим циклом випуску.
Це не схоже на 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, безумовно, не є складнішим, ніж попередні реалізації тих самих компонентів. Це простіше і має меншу надмірність. З іншого боку, побудова простої системної операційної системи залучатиме набагато менше пакетів, ніж традиційне використання Linux. Менше пакетів полегшує побудову вашої системи, позбавляється взаємозалежності та більшої частини різної поведінки всіх задіяних компонентів.
Це не дозволить мені використовувати сценарії оболонки
Це абсолютно неправда. Просто Ми не використовували їх для процесу завантаження, оскільки ми вважаємо, що вони не є найкращим інструментом для цієї конкретної мети, але це не означає, що systemd був несумісний з ними. Ви можете легко запускати сценарії оболонки як служби systemd або демони, ви можете запускати сценарії, написані на cualquier мова як служби systemd, оскільки systemd найменше не хвилює, що знаходиться всередині його виконуваного файлу. З іншого боку, ми в основному використовуємо сценарії оболонки для власних цілей, для встановлення, побудови, тестування systemd. І ви можете вставити сценарії в процес раннього запуску, вони використовуються для звичайних служб, їх можна запускати на останній зупинці, обмежень практично немає.
На цьому етапі я припускаю, що деякі основні переконання могли бути уточнені, незважаючи на те, що я не відчуваю себе прихильником змін і не маю сумнівів щодо “демон, щоб контролювати їх усіх"Я думаю, що врешті-решт ніхто не наважиться сказати, що принаймні це не працює, я навіть знаю деяких користувачів, які помічають, що за допомогою systemd" ПК працює швидше ", але це можуть бути інші речі, про які можна було б обговорити. На даний момент мені залишається лише запросити вас обговорити тут точки зору, які ви маєте щодо менеджера запуску, які прийняли багато дистрибутивів, хоча зараз найбільші реакції спостерігаються у спільноті Debian, яка навіть народилася нова вилка з усім цим. Подобається це вам чи ні - це питання кожного, зі свого боку я просто хочу внести свій внесок у демістифікацію systemd, яка врешті-решт буде присутня у Джессі, наступній стабільній версії Debian.
Я бачив статтю в GUTL (яку, у свою чергу, взяли з Від Абрея)
Системний струм?
Я з тих, хто не читає багато новин, коли щось породжує стільки суперечок, я вважаю за краще дотримуватися більше технічних деталей. Чи це…. іноді я відчуваю, що певні теми перестають бути лише технічною дискусією чи дискусією, і стаю як одна з тих пліток знаменитостей 🙁
Спочатку викликається відкритий рядок від користувача до systemd системна розвідка проти, то Лінус Торвальдс це сказав systemd не все так погано як вони його малюютьі якась причина, якщо вона є), вилка називається марнийd ... Без коментарів ... і нарешті Devuan.
Не скажу, чи так погано, як кажуть, менше погано чи гірше. Система працює для мене без проблем, однак для особистого смаку я віддав би перевагу init, тому що спосіб організації різних речей (наприклад, журнали, наприклад) мені подобається більше, але привіт, якщо systemd стане називатися скаковим конем і його потрібно замінити на у цьому (Це був би наш мул-зграя, який робить все, але повільно?) Ну ... чоловіче, поки зміни не будуть надзвичайно різкими, користувачі можуть адаптуватися без особливих проблем, і система працює краще (так, краще, мені цього недостатньо!), Добре вітаємо 😀
Дуже хороша стаття, я кілька днів працюю в Linux Mint 17.1 Rebecca із systemd, і я відчуваю себе набагато більш рівномірним, ніж у попередніх версіях, я мало що знаю про це, бо я звичайний користувач, який дізнається про це, Буду знати, це перша прочитана стаття, в якій не говориться про шкідників systemD.
Щось, він буде першим, кого ви прочитаєте, а не говорить про нього шкідників, а з іншого боку, скажіть мені, чи використовуєте ви свій монетний двір як сервер? Я маю на увазі, це не завадить вас, якщо у ньому є помилка з час від часу, ні? Ось чому ви використовуєте Mint, і тому це вас не турбує, вам це не подобається, але і система не гвинтить вас. Коли у вас є помилки і через це у вас є серйозні проблеми в серйозних умовах, це вас буде турбувати.
Чувак, якийсь дистрибутив на основі стабільного Debian ви рекомендуєте? Я міг би використовувати Debian, але вам доведеться налаштувати багато речей після встановлення, кодеки тощо ... Що ви рекомендуєте? Дякую.
І як вам вдалося ввести systemd в Linux Mint? Я хотів спробувати вкласти, але я не знаю, чи потрібно робити щось додаткове (до того, що, теоретично, вже приносить Ubuntu), якщо у вас є якийсь посібник з цього питання або щось, що ви можете передати мені, я справді був би вдячний
Дуже хороша стаття. Давайте подивимось, чи читав це антисистемний рух "Талібан" (але я сумніваюся)
У будь-якому випадку, через рік я побачу, як вони використовують SystemD, і вони заперечать те, що сказали рік тому. Так вони є. Стійкий до змін? Звичайно, так.
Ви вважаєте мене талібом за те, що я не хочу приймати Systemd, тоді я вважаю вас талібом за те, що не хочете прийняти те, що я не хочу прийняти Systemd. Ми під рукою 😉
Однак, як сказано в кінці ваших статей:
«elav: Blog Personal / Twitter / G+ / Usuario de ArchLinux. Informático, melómano, blogger y diseñador web. Administrador y Fundador de DesdeLinux.net. »
тобто ви використовуєте одне з перших розподілів, яке прийняв SystemD.
привіт
Добре, дитино.
Без слів !!!!, продовжуйте грати, що життя веселе.
За коментарі, подібні до вашого, шановний Гіскарде, ось чому я відмовляюся від SystemD і того, що він означає.
І якщо після 20 років використання та роботи з Linux і для нього я є талібом; Ну, так нехай буде.
Через рік ми розмовляємо. І елаве, я не згадував про тебе. Ви вбили себе як Чакумбеле.
Подивимось, люди читають і НЕ читають. Є чи немає талібів проти SystemD? Існує! А є інші з іншого боку, ті, хто захищає його від зуба та нігтів, ніби це панацея. Які вони всі? Ні! Зовсім не! Є ті, хто співчуває одному або іншому і бачить хороше і погане як своїх, так і чужих. З тими можна поговорити без проблем. Але вони не будуть заперечувати, що Є ТАЛІБАНИ. І з боку в бік. І якщо когось це вжалило, не розуміючи, що вони цілком можуть НЕ бути талібами, то я зупиняю свою справу, оскільки докази роблять їх винними.
Якщо я буду спілкуватися з кимось про SystemD і з самого початку ця людина називатиме його не своїм іменем, а Systemshit або чимось подібним, я щиро хотів би, щоб вони сказали мені, чи можливо провести бесіду з такою людиною, яка спочатку дискваліфікує суперник. Не може.
У будь-якому випадку, ти повинен читати. Давайте подивимось, якщо я прийду і скажу "є такі ешейфхдуф (вигадане слово), які б'ють дітей, коли вони залишають школу", а дехто приходить захищати "ешейфхдуф", чи не думати, що вони самі є?
Ну, якщо хтось там (не Талібан, будь ласка, і не ешейфхдуф) хоче поговорити про плюси і мінуси init та SystemD (у яких є і хороші, і погані), я із задоволенням буду поруч.
Привіт.
Антисистема талібів? і скажи мені, що ти? просистемний "Талібан"? З іншого боку, чому ви припускаєте, що ми збираємось не читати, а коментувати безпосередньо?, хто такий замкнутий "Талібан", який не допускає обговорення і говорить як LP :: «Це найкраще, повірте мені, я знаю, що роблю ". ?
Я прочитав цілу статтю і можу сказати вам:
Systemd працює на бінарній основі: True
Демістифікація: помилкова
LP неправильно викладає сказане, тобто системне ядро є двійковим, багато, занадто багато, щоб зависнути з PID1, сильно переплетене, настільки, що я запрошую вас подивитися на #devuan, як це коштує чистити, наприклад, увійти systemd та решту пакетів у Debian, враховуючи те, наскільки пов'язаний журнал, який замінює PAM, із системою.
Конфігурація стисла і не дозволяє ВСЕМ, чого б я не хотів, наприклад, деактивувати журнал, оскільки ви не можете ні вбити ПІД, ні зупинити його, ні що інше, тобто модульність? Щонайменше, з sysvinit ви можете вбити все, поки залишився лише init, такий самий вискочка.
===========
"Ця річ монолітна і контролює все".
Поза тим, що це 2 або 69 двійкові файли, вони переплітаються між собою за допомогою dbus і, отже, з усією ОС, не дозволяючи їх легко пов’язати, найяскравіший випадок - журналд, що ви не можете його деактивувати, також , запуск демонів або служб здійснюється за допомогою "одиниць", які є текстовими файлами, але не більше того, аналізуючи systemd і voila, не вносячи жодних модифікацій або хак у сервіси, крім встановленого.
=======
"Не схоже на 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 Translator ... 🙁 Мені було важко зрозуміти деякі абзаци; в будь-якому випадку інформація цінується.
@ Чарлі-Браун, це тому, що Леннарт не дуже добре висловлюється англійською. Ось як негарно це розуміється, читаючи оригінал.
Наведені причини є вагомими, проте, я думаю, що деякі можуть викликати більше запитань. У будь-якому випадку, моя рекомендація тим, хто має можливість: перейти до першоджерела інформації http://0pointer.net/blog/projects/the-biggest-myths.html (на жаль для деяких, це англійською мовою), що є набагато повнішим і доходить до обґрунтування до 30 причин, чому використання SistemD вважається сприятливим.
Ця стаття, яку ви згадали, написана творцем Systemd. Очевидно, що ніхто краще за нього не захищав свою роботу, проте я запрошую вас подивитися це відео http://hackingthesystem4fun.blogspot.com/2014/12/systemd-journald-centos-7-totally.html і вони розкажуть мені свої висновки з цього приводу. Більше не кажу.
Проблема журналів журналів, що знаходяться в двійковому файлі, є одним з найбільш критикованих пунктів, навіть сам Лінус підняв це питання, коли у звіті, де він визнав, що systemd був не таким поганим. Також сам Лінус пояснив, що ви можете створити сценарій, щоб взяти дані журналу та розмістити їх у простому тексті.
Також systemd дозволяє налаштувати розмір двійкового журналу, зменшуючи ризик можливої помилки.
Насправді мистецтво, яке ви цитуєте, є дуже несерйозним, оскільки воно не має натяку на об'єктивність, і навіть змушує мене задуматися, чи справді винна, яку він виявляє, чи це фальшивка (нахуй власне програмне забезпечення, щоб воно видало помилку).
у всіх програмах в якийсь момент виникають помилки, але, здається, вони завжди збираються шукати п'яту ногу кота, щоб знайти щось не так із systemd.
Наприклад: у debian було вирішено, що systemd буде типовим init, але це не заважає використовувати 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.
і потроху мене переконують деякі аргументи антисистемності та серед тих, кого я бачив (якщо щось не так, будь ласка, виправте мене)
Я навіть бачив статтю про те, як вивести з ладу всю систему, коли редагується двійковий журнал, і що в ньому не міститься жодної інформації про те, що файл пошкоджений.
відсутність чіткості в журналах
команда розробників, яка часто ігнорує звіти про помилки
Будучи настільки великим і включаючи стільки речей всередині ініціалізації, система стає набагато нестабільнішою, і якщо ми додаємо такі помилки, як згадана вище, це робить систему без стабільності, яку так сильно характеризує Linux.
це називається модульним, але його частини не можуть працювати без інших частин тієї ж системиd
розробка, яка в довгостроковій перспективі генерує залежності при програмуванні, роблячи таке програмне забезпечення, як gnome, навряд чи портативним для систем без systemd.
він замінює деталі (networkd, logind тощо), які працювали та отримували технічне обслуговування протягом багатьох років, і замінює їх на нові без потреби, які, як правило, мають набагато більше помилок.
З того часу, як я використовую дистрибутиви на основі Arch (Manjaro, Bridge Linux, Antergos), які, очевидно, використовують systemd, я повинен сказати, що не маю претензій щодо його використання та обробки. Запуск служб нескладний - тим більше у Bridge, де за замовчуванням вимкнено bluetooth або modemmanager. Окрім помилки, пов'язаної з hwdb.bin (https://bbs.archlinux.org/viewtopic.php?id=189536) У мене не було багато проблем. Очевидно, я не думаю, що це думка всіх, але особисто я не маю претензій 🙂
Мені не подобається думка, що компанія (Red Hat), яку звинувачують у співпраці з АНБ (задні двері та контроль США), створює систему, за допомогою якої все контролюється. Кільце, щоб контролювати їх усіх, прив'язувати їх у темряві, якщо потрібно.
З іншого боку, я повинен визнати, що Intel IRIS PRO 5200 працює краще для мене, і майже ніколи, якщо не більше, моя графічна система ламається, коли я запускаю openSUSE 13.1. І так, все краще, воно починається і вимикається набагато швидше. Як мені приніс користь простий користувач.
Я виділяю важливу частину
Якщо хтось звинувачує вас у продажі наркотиків, ви автоматично продаєте наркотики?
@juanfgs
Торговець наркотиками ні .... співучасник так.
Боже ... Я б образив тебе, але твої слова роблять це за тебе.
Просто поясніть, що systemd написано, і саме так це слід робити.
Орфографія
Так, це написано systemd, а не system D або System D, або навіть SystemD. І це також не система d. Чому? Оскільки це системний демон, і в Unix / Linux вони мають нижній регістр і отримують суфікси з нижнього регістру d. І оскільки systemd керує системою, це називається systemd. Це все так просто. Але знову ж таки, якщо все, що здається вам занадто простим, назвіть його (але ніколи не пишіть!) System Five Hundred, оскільки D - це римська цифра для 500 (це також уточнює відношення до системи V, так?). Єдина ситуація, коли ми вважаємо нормальним використовувати велику літеру в назві (але це теж не подобається), це якщо ви починаєте речення з systemd. У високі свята ви також можете писати це sÿstëmd. Але знову ж таки, Система D - це неприйнятний варіант написання і щось зовсім інше (хоч і підходить).
http://freedesktop.org/wiki/Software/systemd/
Тут також? Ви вкладаєте це в GUTL .. але людино, всі говорять Linux, а не GNU / Linux, тому з SystemD те саме.
Я кажу вам, що не потрібно використовувати систему журналу або cron, яку надає systemD, ви можете слідувати syslog-ng та cronie для цієї чи інших альтернатив
Я використовую systemD в ArchLinux, оскільки я був у aur, і це здається простішим в обробці, ніж похідна форма debian та redhat, у ньому є безліч консольних команд, які позбавляють вас від редагування текстових файлів та спрощують складання скриптів. Конфігурація установки (пам'ятайте що в арці все встановлюється консоллю)
І не в останню чергу система запускається швидко, в arch ви можете запускати служби паралельно при запуску системи, але це було ризиковано
Що я вважаю поганим у цій проблемі, так це те, що більшість приймає сторону, або ви прихильник системи чи антисистеми, і я думаю, що в цьому є свої хороші і погані речі, я користувач, і я почав трохи грати з systemd, Насправді хороші речі, стартап швидший і менш складний, ніж решта ініціатив, хоча випуск журналу мене також дуже турбує.
Я розумію, що ті, хто дійсно можуть сказати, добре це чи погано, це сисадміни або експерти з цього питання, але мені здається, що системна суєта деякий час тому перестала бути чимось технічним і стала чимось більш "шоу-стоп" з моєї сторони я трохи проти, але я не вважаю себе ані проти, ані проти
@KZKG_Gaara
Я бачу, що багато з того, що ви коментуєте тут, є таким самим, як Леннарт опублікував у своєму блозі, точніше в цій публікації: http://0pointer.de/blog/projects/the-biggest-myths.html.
Звичайно, пост мав певні "уточнення" і залишив осторонь певний технічний зміст, щоб було легко засвоїти інформацію для тих, хто збирається його прочитати, але ми будемо серйозними та щирими, навіть якщо правда боляче: у systemd є багато речей, які Леннарт заперечує, що їх немає, і багато іншого насправді. І в цьому сенсі я пояснюю частково.
1. - Леннарт каже, що він не здутий і що у нього немає синдрому високого NIH (не вигаданий тут синдром). Якщо так, будь ласка, хтось пояснить мені: Чому у ініціатора повинен бути мережевий контроль (systemd-networkd), dns (systemd-networkd), m-dns (systemd-networkd), журнали (journald), coredumps (systemd -coredump), налагодження (systemd-coredump і journald), acpi (вхід), ескалація привілеїв (вхід), контроль ntp (systemd-timesyncd), контроль над dev (systemd взяв всю функціональність udev), контроль / dev / random (випадкове число генератор) та найновіший контроль над TTY (з консоллю systemd)? Чи не було БАГАТО інструментів, створених для таких цілей, які systemd тепер додає свої, деякі з ексклюзивним доступом (case journald)? Яке логічне та прийнятне пояснення ви даєте мені для ініціативи, щоб мати можливість зламати налагодження ядра та cmdline? Додайте до цього контроль над kdbus, наступним IPC, який буде інтегрований у ядро. Звичайно, вони скажуть мені тут: «Але ти можеш встановити інший інструмент для контролю всього цього». І якщо це правда, але багато з цих інструментів отримують лише потік даних, переданих systemd, як у випадку syslog та rsyslog, які підключаються до даних / потоку, які надає журналд, щоб інші інструменти могли ПЕРЕГЛЯНУТИ, що привід журналда , зрештою, це просто означає, що у вас є два інструменти, які роблять одне і те ж, і один з них - це ящик пандори. (Будь ласка, не кажіть мені, що код може бути перевірений, тому що я запрошую когось "закурити" код журналу та його фреймворк за допомогою systemd та інших відповідних інструментів)
2. - Леннарт також повідомляє нам, що systemd пропонує підтримку сценаріїв SysV та LSB. Це "напівправда", "біла брехня", так би мовити, адже правда полягає в тому, що systemd-214 не пропонує підтримку скриптів bash, SysV або LSB, і це стосується його приміток до випуску до цієї версії.
3. - Який systemd не є портативним? Це ще один спірний момент. У BSD це погано працює, у BSD серед інших інструментів, які потрібно запускати systemd, немає Cgroups. Але це з причини системного дизайну, а не тому, що це не портативно. Поки ядро BSD не досягне мінімуму для його підтримки, systemd не працюватиме на цій платформі, і це ні в чому не винна, лише те, що BSD не зацікавлене, а також Lennart. Це так просто. Тепер підтримка інших бібліотек 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. Ви просто трактуєте побачене зі страхом, що призводить до перебільшень. Ні чітких і чітко визначених переваг, ні недоліків.
Крім того, ця інтеграція дозволяє стандартизувати, про яку ви навіть говорили. На systemd працює не тільки Red Hat, але й різні компанії та волонтери з інших дистрибуцій.
Я думаю, що помилка полягає в тому, що робота systemd не вивчається належним чином.
Я бачу вагомі причини в аналізі Юкітеру. Зверніть увагу, що замість страху я бачу строгість, точність і чіткість. Це має бути проблема очного лікаря.
Це не страх (я не боюся шматка коду) і не перебільшення (все, що я сказав тут, задокументовано, і я передав багато інформації, яка це підтверджує, інформація, яка, до речі, виходить зі списків а з розуму / голосу / власного почерку Леннарта, а не з коментарів блогера), це РЕАЛІТА.
systemd робить все це і багато іншого, і це щось СТРОЙЛЕ (інша концепція, ніж боятися), оскільки вона, безумовно, бере атрибуції і робить речі, які на даний момент можна зробити іншими засобами, і які, до речі, працюють краще і стабільніше . systemd дуже схожий на Windows, і цього неможливо приховати, просто знайте, що роблять userinit.exe, svchost.exe, smss.exe та інші залежності, і порівняйте їх із systemd, подібність настільки велика, що це погана ідея. Тепер, звичайно, systemd може мати кращу якість, ніж його аналог Windows (або може статися навпаки, ніхто насправді не знає, якщо ви не програмуєте для Microsoft), але ви не можете звинуватити мене в ЧИСЛОСТІ І СТРАХУВАННІ, коли читаєте самого Леннарта у списку, створення цілком нової бібліотеки C, тому що він набрид Glibc, а для напа, підкиньте маленький і незначний підказку, що цей libc можна використовувати для побудови всіх пакунків Fedora. І якщо ви вважаєте, що це брехня, і я перебільшую, я залишу вам повідомлення за цим посиланням: http://lists.freedesktop.org/archives/systemd-devel/2013-March/010062.html (англійською)
А тепер скажіть мені, якщо це перебільшення, сказати перед усіма цими речами, що як тільки Лінус вирішить, що CONFIG_VT таким, яким він є, він повинен вийти з ядра (ситуація, яка існує довгий час) і передати його в користувацький простір, не трапляйтеся божевільної речі, наприклад, якщо systemd-consoled - це сильна залежність майже для будь-якої інсталяції Linux (щось має обробляти VT, чи не так?), що не буде ставити різні несистемні дистрибутиви в центрі уваги, щоб змусити перемикач. Якщо ви думаєте, що це розтяжка, дозвольте мені сказати вам, що ви не уявляєте, на що здатний і що робить Леннарт, оскільки його останні зміни впливають на розвиток форка 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, і я не знаю, чи через чисте технічне незнання, чи тому, що вони не скаржились би на це.
Отже, ЗА ВАМИ, ми всі антисистемні отруйні та купоросні, що єдине, чого ми досягаємо, це роз’єднаність, проблеми тощо. Дозвольте сказати вам, що це найбільше обурення, яке мені вдалося прочитати тут. Я не знаю, чому просистемні турбують, коли виявляються структурні проблеми системи, які, очевидно, в якийсь момент вплинуть на них, бо з ними зараз нічого не могло статися, але в якийсь момент вони будуть. це стане, і тоді якийсь антисистемний нагадає їм слова, які вони говорили багато разів, і ніхто їх не зупиняв, і, можливо, якийсь інший антисистемний допоможе їм.
En lo personal, no me gusta systemd, pero eso no significa que no use el init, tengo que hacerlo, porque precisamente en mi trabajo si tengo que tocar alguna maquina con ese init, debo tener conocimiento de como manejarlo. Además en lo personal también lo he usado desde que llego a Archlinux e incluso en Debian y Gentoo, así que no me venga a decir que mi visión es sesgada por no hacer uso de systemd, yo le he usado, y se de que pata renquea, y si tengo que ayudar a alguien acá en el foro DesdeLinux o en IRC o la lista de Debian (que es la distro donde yo más tiempo he estado y aún uso en mi trabajo) lo haré con gusto, porque precisamente si algo me agrada de la comunidad Linux, es que pese a la diferencia siempre se ayuda.
Тепер перейти на BSD це можливо, але я зроблю це лише в тому випадку, якщо systemd стане настільки вірулентним, що не дозволить мені використовувати будь-який інший варіант, тим часом я залишаюся на Linux, відключаючи все це божевілля, включаючи багато Групує речі.
!=
Знову ти скручуєш слова, щоб відповідати мові. Ви дуже хороший матеріал для політика / журналіста.
Я уточнюю, моя проблема не в тому, що вони згадують про технічні проблеми Systemd, справа в тому, що вони багато разів завантажують свою промову брехнею, а саме:
Що якщо systemd збирається змусити вас використовувати сервер microhttpd (який є необов’язковим модулем, який НЕ встановлюється за замовчуванням), що якщо systemd є єдиним двійковим файлом, цей systemd буде закритий, оскільки lennart платить Microsoft, то двійкові журнали Вони є обов’язковими. Ніхто не хоче системності, а її прийняття здійснюється політичним лобі.
Ось які шоки, брехня. Якби це було розумне обговорення, воно того варте, але це лише хороший FUD.
Те, що вам не подобається, мені здається ідеальним, я не люблю багато програмного забезпечення, навіть мов програмування, дистрибутивів та інших, але я не вигадую про це речей, і я не читаю з точністю те, що хочу прочитати завантажуючи мої висловлювання особистими почуттями, щоб пошкодити імідж людей, які його розвивають.
@juanfgs вибачте, але я не той, хто називає певну групу людей "отруйними та купоросистими" просто тому, що їм не подобається програмне забезпечення.
Знову ж таки, скручування речень, щоб стати жертвою.
@juanfgs ще раз кажу вам, що ви сказали, перевірте ваші слова, я не спотворюю ваші слова, я просто зробив копію / вставку ваших слів у коментарі 59.
Я цитую свій текстовий капо-коментар, той, який вам доведеться прочитати ще раз - це ви, тому що ви не хочете розуміти або ви не знаєте, як сперечатися. Ви виймаєте речі з контексту і інтерпретуєте їх так, як вони вам співають. Отже, якщо ви хочете вибрати жити у світі, де вас почувають ображеними, оскільки ваші аргументи оскаржуються, Леннарт, Red Hat та Microsoft переслідують вас, це тому, що ви вирішили в це повірити.
Тут коротко, бо я розумію, що ти не розумна людина, бо не хочеш розуміти, хочеш інтерпретувати речі так, як вважаєш за потрібне.
Якщо ви хочете образитися, ображайтесь, але це ваша проблема, а не решта світу.
@juanfgs Мене не турбують ваші коментарі, правда, я не бачу причини, ми сперечаємось, цивілізовані люди сперечаються, не турбуючись про це (саме так я думаю).
Тепер, якщо ви хочете позначати людей, попереджати (або як би ви хотіли це називати) людей за їх виступи чи дії (можливо, вам слід прочитати мій коментар №64 і виміряти його широту), це ваша проблема, обмежтеся цими діями до себе і не залишайте інших поза цією сумкою.
Привіт.
"Більшість антисистемних", "майже всі", "всі", "якась частина антисистемних" ... ми відхиляємося, Маріано, ми відхиляємось. У цій справі: я ніде не бачу, щоб Юкітеру виступив із сенсаційною промовою, заснованою на здогадах (маючи на увазі його аналіз таким чином, щось викривлене), навпаки, він виробив вагомі аргументи щодо недоліків systemd, заснованих на відповідні запитання та матеріали, взяті зі списків розсилки та слідів помилок (а також ввічливо і цивілізовано). Можливо, з цієї причини він дратує деяких, і вони нападають на нього за першим коментарем, щоб дискредитувати та дискваліфікувати його (цього разу отруйним способом).
Якщо ви бачите, що дискурс більшості антисистемних є отруйним та купоросовим, то, що я бачу в дискурсі деяких просистемних (я не знаю, більшість це чи меншість), це істерика та переслідування тих, хто, точно, вони наводять вагомі аргументи серед усього шуму. Те, що в моїй країні ми називаємо переслідуванням інакомислення.
Чи добре у вас в systemd виходить? Чудово, мені здається чудовим, але нехай ті, хто не думає однаково, висловлюють свої застереження (операційна система може працювати не однаково).
привіт
Ну, до речі, чому будь-яка системна помилка підірвана настільки, щоб витратити весь компонент, але інші, такі як GCC, glibc або навіть ядро, до цього моменту не критикували багатьох своїх помилок?
Ви самі сказали, glibc давно затягує проблеми. З часом Llvm має переваги над GCC. І тут я не бачу тієї самої критики.
Чому б не зробити те саме з іншими проектами?
Для мене це просто колективний та ірраціональний страх.
У Glibc є свої помилки, їх ніхто не може приховати, є величезні помилки Glibc, які впливають на ядро та сотні виконуваних файлів. Різниця між Glibc та systemd полягає в тому, що перший є базою, з якої ТИСЯЧИ програмних проектів можуть бути перетворені у двійкові файли, тоді як systemd - це ініціатива, мета якої - бути стабільною, перевіреною та практично безпомилковою частиною. Мало того, Glibc повинен пристосуватись до сотень різної апаратної архітектури (ЦП), до різних прапорів оптимізації та унікальних характеристик ЦП, до різних форм оптимізації програмного забезпечення, набагато важчої та складнішої роботи, ніж у systemd. Я насправді не бачу жодного способу представити порівняння між двома проектами в одному масштабі.
Те саме стосується GCC, GCC - це компілятор, який, до речі, підтримує багато мов (загалом 13, враховуючи неофіційні), і має характеристики, дуже схожі на Glibc, підтримуючи багато архітектур (70 архітектур для версії 4.9), двійкову оптимізацію прапори, прапори оптимізації процесора та багато інших функцій. Зараз вони на тому самому рівні складності, компілятор з ініціатором. Відповідь більш ніж очевидна, починаючи з того, що systemd знаходиться на мові C, і багато коду GCC знаходиться в асемблері, або вам потрібно використовувати асемблер, щоб змусити речі працювати в двійковому вигляді, щось дещо `` важко зробити ''.
Що не так із GCC та Glibc? Ясно. Навіть Лінус дав їм свою атаку, але в GCC та Glibc у них є щось позитивне, що в systemd про них часто забувають, тобто, повідомляється про помилку, бачена помилка, виправлена помилка.
- будь ласка, хтось пояснить мені: чому ініціатор повинен контролювати:
мережі (systemd-networkd),
dns (systemd-networkd),
m-dns (systemd-networkd), л
ог (журнал),
coredump (systemd-coredump),
налагодження (systemd-coredump та journald),
acpi (вхід), ескалація привілеїв (вхід),
ntp(systemd-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)?
Я не збираюся заперечувати, що тема журналу зберігає інформацію в двійковому файлі - це найслабше, що захищається, але це не кінець світу, їх можна зберегти у простому тексті
- Яке логічне та прийнятне пояснення ви даєте мені, що init здатний зламати налагодження ядра та cmdline?
Мммммммммм …………………. зламати ядро ……. 5000000 речей можуть зламати ядро
- Додайте до цього контролю над kdbus, наступним IPC, який буде інтегрований у ядро.
На думку lennart Це має позитивні стосунки для розробників, і systemd запропонує інструменти для відкриття dbus адміністраторам, а також надасть інтерфейси журналу та мережевої шини
- Звичайно, вони скажуть мені тут: "Але ви можете встановити інший інструмент, щоб контролювати все це". І якщо це правда, але багато з цих інструментів отримують лише потік даних, переданих systemd, як у випадку syslog та rsyslog, ... .. це означає лише, що у вас є два інструменти, які виконують те саме, і один із їх - коробка Пандори. (Будь ласка, не кажіть мені, що код може бути перевірений, тому що я запрошую когось «закурити» код журналу та його фреймворк за допомогою systemd та інших відповідних інструментів)
тут ми входимо в теорію змови !!!!! це худе безкоштовне програмне забезпечення, нічого не приховане
3. - Який systemd не є портативним? Це ще один спірний момент. У BSD це погано працює, у BSD серед інших інструментів, які потрібно запускати systemd, немає Cgroups. Але це з причини системного дизайну, а не тому, що це не портативно. Поки ядро BSD не досягне мінімуму для його підтримки, systemd не працюватиме на цій платформі, і це ні в чому не винна, лише те, що BSD не зацікавлене, а також Lennart.
Ну, це не зовсім правильно, розробники 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, і ти нічого не кажеш
@rolo
Тепер перелічіть, які саме дистрибутиви взяли systemd і створили ці 90 бінарних файлів в окремих пакетах, це буде 91 пакет із systemd.
І при встановленні systemd він не запитує у мене жодного з цих 90 пакетів як залежності.
Серйозно, і я знову наполягаю ... перешліть мені, будь ласка, параметри –configure-help, що я хочу зробити 91 пакет, що складається вручну за допомогою make.
Немає гіршого сліпого, ніж той, хто не хоче бачити ... хлопчики, це вода і олія, здається, все ще є вперті люди, які не бачать реальності того, що чекає червона шахта.
@rolo Я хочу, щоб ти встановив systemd та видалив journald, systemd-udev та coredump, а також використовував такі опції, як eudev та syslog, щоб перевірити, чи зможеш ти.
Цей коментар не міг змусити мене серйозніше сміятися, я вмираю. 😀
Досить серйозно, вони справді стикаються з проблемою читання, замість того, щоб приставати до променя в оці.
Крім того, ніхто не забуває, що Кей Сіверс не просто зламав ядро cmdline, але хотів його замовкнути, адже "загальний - це загальний".
Іншими словами, за Вашими словами, той факт, що два процеси передають інформацію, робить їх настільки сполученими, що той факт, що один не вдається, робить інший високою ймовірністю збою ... з якої теорії розробки програмного забезпечення Ви це отримали? Я погоджуюсь з @pamp, що ви говорите з ірраціонального та упередженого страху.
І інше ваше велике питання, чому systemd повинен контролювати стільки речей? Проста відповідь: оскільки з sysvinit та всіма іншими перевагами init, нещодавно введеними в ядро Linux, витрачаються даремно, поки ніхто не використовує їх у користувацькому просторі, вони "озлоблені" (як ми говоримо на Кубі ... ну даремно) без когось я їх використовую, і вони дають дуже хороші переваги в ефективному використанні апаратних ресурсів (ЦП, оперативної пам'яті, вводу-виводу тощо), включаючи групи. Те, що робить systemd, - це саме те, що передає ці хороші функціональні можливості ядро Linux на службу користувачеві, але для цього він повинен бути тим, хто ініціює цих демонів.
Я думаю, ви неправильно читали та аналізували (аналіз важливий), або ви просто не дали собі шансу зробити це. Те, що два процеси передають інформацію, не є причиною для ламання системи, однак, коли у вас є двійкові файли з динамічними діями, такі як керування мережею, журнали або супутні дані, передаючи інформацію безпосередньо в init, все може піти не так, і вони підуть не так, тому що якщо деякі з бінарних файлів зламаються, шанси зламати решту набагато вищі, і це цілком реалістично, і це сталося, нещодавно збій ядра cmdline, проблеми з acpi, які розробники Nvidia мали завдяки systemd-212, все це зразок того, що я кажу.
@Dariem
Якщо ви не можете скомпілювати кожен з цих двійкових файлів в окремі пакети, ви змушуєте це зробити, оскільки ви хочете встановити один, вам доведеться встановити всі з них, коли ви встановите їх усі, виявиться, що ви наступаєте на інші пакети, які неможливо встановити, оскільки частини 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, мої робочі столи можуть зникати, тому що вони ні на що не вплинуть на мене.
@ анонімний питання полягає в тому, що видалення 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 (привіт, devuan), будуть використовувати if або if eudev.
Те, що сталося з оригінальним udev, відбудеться, systemd з’їв це, але тут ядро - це те, що продиктовано API для взаємодії з консолями за допомогою DRM / KMS ... Я вже хотів побачити urxvt, який використовує це ...
Я погоджуюсь з тим, що той, хто використовує systemd, не матиме можливості щось змінити ... повне і жорстке накладення і, як я вже говорив раніше ... кричати на кладовище.
@ anonymous, безумовно, інша можливість - це те, що ви скажете, eudev прийме більше зусиль у цьому відношенні та буде залишати відкритими варіанти вибору різних інструментів.
PS: Як ви говорите, було б цікаво подивитися, як VT використовують переваги KMS / DRM разом з fbdev 😀
Ви точно повторили концепцію, яку я вас критикував, тому що жодного разу я не говорив про систему, я говорив про зв'язок між процесами, і ще раз повторюю, звідки ви це берете, оскільки два процеси спілкуються, смерть одного означає, що інший має широкі можливості Померти? Поясніть мені, як два процеси, що перебувають в окремих просторах пам'яті, можуть взаємно впливати на внутрішню поведінку один одного. Давайте подивимось, чи поясню я сам, з точки зору одного з цих процесів, він отримує доступ лише до механізму IPC (незалежно від того, що було визначено для зв'язку з системними процесами). Якщо програміст настільки погано не включав код, який може мати справу з несподіваними введенням і виведенням, це вже інше, але це не має нічого спільного з одним процесом, що впливає на внутрішні органи іншого. Якщо 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 був запис розділу (не важливо для системи, зрозумійте a / mnt / Disk160GB), і це не міг ' Неможливо встановити з якихось причин, монтування просто пропустили, видали попереджувальне повідомлення та продовжили процес завантаження. Тепер, systemd - це вже інша історія, незважаючи на свою модульність, якщо у вас є запис у / etc / fstab і systemd з якихось причин бачить, що його неможливо змонтувати, він не лише чекає, поки розділ стане доступним (звичайна запрограмована поведінка ) для його складання, але якщо час закінчується, ваша система зупиняється, і ви не можете зробити нічого іншого, як увійти в режим відновлення та видалити цей рядок з / etc / fstab, щось насправді не вдається. Ця маленька деталь більше не залишається під час автоматичного монтажу в завантаженні, і весь процес зупиняється, спочатку (systemd-) маленька деталь була потворнішою, тому що дамп щойно з’явився, і вам довелося перезапустити. Хтось, хто пройшов деталі, розповідає вам.
Ще один приклад, який я можу навести, - coredumpd в systemd. coredumpd за замовчуванням передає всю свою інформацію журналу, щоб останній записав захоплену інформацію на диск, наскільки добре, ми використовуємо модульність systemd на свою користь. Але трапляється іноді, коли спільні відвали дуже великі, настільки великі, що вони можуть зайняти кілька Гб, і в процесі передачі інформації з coredump на журнал, а потім на диск, трапляються дивні речі, як Xorg перестає працювати і навіть ядро паніка. Звичайно, це трапляється не тільки з systemd, але і те, як він розроблений, збільшує коефіцієнт відмов і створює інші неприємні деталі (серед них збільшення споживання пам'яті, пошкодження журналу, неповні дампи), кому довелося працювати з спільним скидом KDE. Ви, безсумнівно, пережили кілька таких епізодів, і ви зрозуміли важливість наявності опції синхронізації в / etc / fstab для вашого дампа-розділу, і ви, безумовно, будете ненавидіти той факт, що ви не можете використовувати якусь іншу опцію для обробки дампів, якщо ви встановили systemd. Приклад того, що може статися з systemd-coredumpd.
https://bugs.archlinux.org/task/41728
Тепер, щоб закінчити:
Хіба вони не повинні бути модульними програмами та процесами? Так, вони модульні. Ядро - це єдина монолітна річ, про яку я вже говорив тут, але вона також приймає модулі (LKM), тому це було б своєрідним гібридним ядром, хоча його основна форма проектування не розроблена в такому типі структури, і це робить його трохи нестабільний за певних обставин.
Ця модульність не повинна дозволити мені змусити мої процеси та систему не виходити з ладу, якщо щось піде не так? Це правда, модульність - це міра, призначена для досягнення високого ступеня стабільності та надійності, але це не 100% безпомилкова міра, тому що якщо щось може піти не так, це просто піде не так, як би модульно це не було, реальність.
Який systemd повинен мати контроль над усім, щоб зробити можливим використання cgroups та інших опцій, доданих до ядра? Цілком помилковий. Це зовсім не потрібно, systemd міг би мати інтерфейс для управління запуском та призначенням cgroups процесам та демонам, які будуть у системі, без необхідності брати на себе обсяг послуг, які вона зараз має, і найкращим прикладом цього є; що OpenRC також здатний використовувати cgroups, і не з цієї причини виконувати це завдання не так інвазивно.
Що я заангажований і страшний, говорячи про systemd? Я не уявляю, звідки він це бере, тому що, як ви бачите мою відповідь, я цього не боюся, я кажу лише про аспекти, які мені не подобаються в systemd, і все, не покладаючись на думки третіх сторін.
Нарешті, ви кажете, що: "Якщо програміст був настільки поганим, що не включав код, який може мати справу з несподіваними введенням і виведенням, це щось інше ..."
Звичайно, сказати, що програміст за те, що не включає код, який обробляє ВСІ можливі способи, якими його програма може зламатись через якийсь помилковий введення даних, є ПОРИМ, мені здається обуренням. Яким би хорошим програмістом він не був, людина не в змозі розробити безпомилкову та безпечну програму, ЗАВЖДИ буде помилка, яка так чи інакше виявиться, і коли це станеться, це буде завдяки випадковий збій під час його використання, хакером чи зломщиком, що експлуатує вразливість, переглядом та аудитом коду або будь-якими іншими засобами, на які програміст може розраховувати. Краще виміряти слова, перш ніж говорити щось подібне.
Привіт.
Наведений вами приклад Xorg є найменш доречним, оскільки всі, хто зазнав переходу на KMS / DRM, знають, що проблема викликана помилками модулів ядра для управління KMS, які надаються розробниками драйверів Xorg. Помилка в модулі KMS те саме, що і паніка ядра, вона не має нічого спільного зі зв'язком між процесами, тому що в цьому випадку це Xorg робить системний виклик (syscall), так що ядро змінює режим екрану, тобто там задіяний лише один процес (Xorg), який викликає ядро, і нічого спільного з тим, з чим ми маємо справу тут.
Поточна поведінка systemd, коли не знаходить точки монтування, не має значення, незалежно від того, що це функціонал, який комусь може не сподобатися, який вирішується проханням підтримати іншу поведінку, тобто ігнорування невдалого монтування. Випадковість, яка мала місце раніше, могла бути пов’язана з різними причинами, про які можна було лише здогадуватися, але той факт, що виконання не продовжилося, може бути пов’язаний із бажаною поведінкою, оскільки ви говорите, що її потрібно було перезапустити, а не ядром паніка або автоматичний перезапуск. Оскільки я цього не пройшов, я не можу дати свою думку.
Що стосується проблеми, яку ви поставили з systemd-coredumpd, і посилання на звіт про помилку, все вказує на те, що ця проблема в Arch Linux була пов’язана зі стисненням, яке вони увімкнули systemd, коли вони компілювали його для цього розподілу. Це більше схоже на проблему з алгоритмом стиснення, ніж із самим systemd. Операційна система не виходить з ладу, швидше алгоритм стиснення, який використовується для зберігання спільних відвалів, здається, виснажує систему, і це винна розробниками Arch Linux, які скомпілювали systemd. Однак, systemd має налаштування обмеження споживання ресурсів та увімкнення / вимкнення захоплення всіх спільних відвалів, про які повідомляє ядро. Можливо, архітерам 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, щоб він поводився як windows .. якщо все працює добре, і це полягає в розробці та еволюції Linux, в чому проблема ... кожен проект на початку може мати помилки змін, якщо програмне забезпечення тощо було ідеальним, Ми люди, але тому маємо помилки.
що якщо systemd вийде з ладу, система вийде з ладу ... і якщо ядро, xorg, grub вийде з ладу ... є люди, які, оновлюючи ядро на своєму ПК або ноутбуці, втрачають систему ... то тому, що наполягання на досконалість чогось ...
як ніби якась система, яка вийшла, не мала помилок помилок або чогось у своєму зародку або навіть вже у своєму зрілості мала збої
Systemd було введено як стандарт із брудною грою, це є обов'язковою залежністю для багатьох пакетів, оскільки багато програм були поглинені systemd або тому, що вони їх підтримували, або тому, що вони повільно усували їх, оскільки вони більше не були актуальними, оскільки systemd вже забезпечував щось подібне.
Це обмежує свободу вибору, тобто дистрибутиви не можуть вибрати НЕ використовувати systemd, вони можуть спробувати протистояти, як gentoo, але це більше тимчасове рішення для systemd, openrc - це просто менеджер послуг, що підтримується sysv для init та instcripts distro , systemd надає більше функціональних можливостей, ніж openrc, і має нові функції щодня. Нове програмне забезпечення підтримує systemd і вимагає впровадження чогось подібного, що в кінцевому підсумку робить інші ініціативи більш складними та більш схожими на systemd, а це не те, що ви хочете.
Systemd робить багато речей у порівнянні зі старим init, який просто читає пару рядків з / etc / inittab, а потім завантажує кожен з initscripts та їх конфігурації відповідно до рівня виконання. Старий підхід був набагато простішим та незалежнішим. Ми перебуваємо на стадії переходу до нової ери однорідності, рішення не існує, шлях, який він переважає, не зупинити.
Через кілька років практично не буде різниці між використанням debian, використанням arch або fedora, ідентичність кожного дистрибутиву буде втрачена, якщо ми будемо продовжувати так, і systemd з кожним днем стане більш нав'язливим, що навіть стане частиною назви системи ( systemd / gnu / linux)
LOL
Плакати до церкви>: D
Що каже Дон KZKG, я залишаю вам це: https://blog.desdelinux.net/systemd-vs-inteligencia/#comment-127648
Проблема в тому, що ти аргентинець (я теж), але спосіб висловити себе, що більшість аргентинських лінуксерів, які я читав, насправді викликає занепокоєння, хоча також кажуть, що світ вільного програмного забезпечення приваблює певних людей. Я рятую те, що ви не вважаєте себе аргентинцем, але це, на жаль, показує ліги.
уюййй .. той хлопчик упав із важкою артилерією ..
сильний коментар !!
Жужу .. ..pochoclos .. xD
З цієї статті випливає, що все, що вони роблять, це "нав'язувати" систему. Я не вступаю, щоб оцінити, чи краще (а що ні), чи гірше. Те, що я кажу, повторюю, наголошую і наголошую, полягає в тому, що я насправді не хочу, щоб мені щось нав'язували.
Фрази на кшталт: "Ми просто не використовуємо їх для процесу завантаження, оскільки ми вважаємо, що вони не є найкращим інструментом для цієї конкретної мети".
І хто ти такий, щоб мені сказати, чи хочу я використовувати той чи інший інструмент?
Там кожен. Я просто не використовую його, крапка, і поки я не можу, я не буду.
Підписано. Талібан.
(Це те, що мене розважає клоун)
часто болить голова з цією темою !!!! X_X
Я керував серверами з Centos 6, і перехід на 7 з systemd мені нічого не коштував, не плачте, життя триває.
Вибачте, але я багато читаю, що нагадує мені класичний дискурс "сервер Windows - Сертифікований VS сервер Linux - 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-е - Що поганого в складності? Напевно, ти все ще пам’ятаєш, коли давав лінійне програмування, і що, безумовно, в якийсь момент ти сказав ... «А чому я хочу навчитися працювати над об’єктами, якщо тепер я можу все робити, а в іншому вони дозволяють мені користуватися?» ... (facepalm через пару місяців чудово, якщо xD)
Давайте прояснимо. Поточний init (і я включаю systemd) має багато недоліків, які можна заповнити, лише додавши складності. Немає іншого, оскільки для того, щоб зростала взаємопов'язана система, вона повинна рости в ускладненнях, ризикуючи мати слабку частину, але це краще, ніж залишатися в стані нерухомості.
Потрібно пройти довгий шлях, і якщо… sistemd - це не все рішення. Але жоден з них не залишається з SysVinit.
PS: Зверніть увагу на іронію, що я використав комп’ютер свого колеги «Я чіпляюся до захисника Windows-сервера», щоб він міг його прочитати. xD
Тільки одне - захисникам інших ІНІТ, які надають технічні дані та посилання ... ЧАПО !!! Я люблю бачити такі аргументи та дані. Зауважимо, дані до жовтня 2014 року є лише історичними.
Багато речей, які обговорюються, вже виправлено, а багато тестових стендів, опублікованих у 2013 році, вже переглянуто.
@rolo
Якщо це правда, якщо ви бачили відео, чого НЕ ВИ робили, ви бачите, що журнал становить 8 МБ, нічого більше і так далі, і все пошкоджується, до речі, чи можете ви надіслати результат журналу до syslog просто текст? Так, але навіть якщо ви торкаєтеся журналів, створених журналдом, це трапляється, система зависає і, зрозуміло, давайте подивимось, журнал зависає на PID1 разом із такими складними речами, як systemd, він не працює, здається, у ньому немає пошкоджена частина коду, яка не дозволяє редагувати щось інше, ніж той самий PID журналу, а також не має можливості продовжувати писати за межами журналу, що показує, що окрім мислення у режимі Windows, LP - поганий програміст .
Не кажіть мені, що це буде лише в centos, найстабільнішій версії дистрибутива, що використовує systemd, клон RHEL7, і я не повідомляю і не планую повідомляти про помилку.
Правда полягає в тому, що чим більше я читаю про системні коментарі, я усвідомлюю, що вони насправді схожі на релігію, або ви за, або ви ворог, але, з тих релігій типу ІДІЛ, релігій Ісламської держави, цілком екстремістських, насправді, я знаю з досвіду, системні коханці, вони так думають, або ти з ними, або ти ворог. Це те, що Леннарт пропагує своєю зарозумілістю, і, будь ласка, не трахайте мене з підтримкою Лінусом, systemd не був цим, ЦЕ НЕ БИЛО, я використовував systemd, як тільки він вийшов у Fedora 15, і це був просто швидший init, це не замінив модульність GNU / Linux.
Якщо я вб'ю rsyslog, пошкоджую його журнали або замінюю його кресленням, нічого більше, лише те, що у мене закінчився журнал, нічого не зависає, система не постраждала.
@ Рафаель Мардохай
Це те, що робить Devuan, це те, що робив Void Linux та інші, хто тримається подалі від systemd.
@Юкітеру
Напевно вас ніхто не читає, як кажуть мені "Талібан", вони вас не читають, тому що ви користуєтеся вікнами або ви коментували з нього, і тому, що я вважаю, що мало хто із системних любителів розуміє технічну частину того, що ви говорите, і в цьому полягає проблема.
======
Правда в тому, що я все ще думаю, що людина, відома ще в 2006 році, мала щось у своєму відношенні:
"Я не хочу, щоб люди користувались Linux або не знали про це, ці хлопці з Ubuntu наповнили мене"
Я- "Чому?"
"Коли щось стає відомим для широких мас, воно засмічує, трахається, і є безліч його зразків"
Я- "подобається який?"
"Подивіться, що сталося з Debian, тепер у нього дурний син на ім'я Ubuntu, і пам'ятайте, через кілька років у нас будуть" хакери "і" виродки ", які смоктали Ubuntu, і вони не знатимуть, як відрізнити Ext3 від NTFS"
Щось було правильно…. systemd перемагає серед тих, хто знає, як говорить Аллан Макрей, тому що йому все одно, як запускається його машина, для нього це кнопка, магія, і я маю підказку. Серед тих, кого не цікавить більше, ніж "робота" з приємними функціями, загалом, для серверного використання LFS або Gentoo або BSD насправді, а потім тих, хто любить це, тому що він швидше включає свій ПК із кольоровими вогнями, красивими звуками та азартними іграми , але вони не знають, що таке syscall.
@SynFlag, якщо вони не читають це за власним рішенням щодо ОС, яку я використовую, якщо я працюю і коментую з ПК з Windows, це тому, що це єдине, що у мене є під рукою, крім сервера, який є в Debian Wheezy і, очевидно, з сервера я не можу тут коментувати.
Навіть вдома мене змусили використовувати ПК моєї сестри, тому що мій ПК загинув (МБ та джерело живлення змовилися проти мене), і навіть коли я встигаю, я встановлюю LiveCD і використовую Sabayon (з OpenRC) для коментарів тут, як я роблю саме тоді, коли пишу ці слова.
Тепер, якщо вони мені скажуть або вважають, що я антисистемний таліб, це для мене не має значення. Як я вже говорив, я використовував systemd, і я знаю, що він кульгає, і не тільки це, я зазвичай багато читаю список systemd, щоб дізнатись про речі, які поставляються в нових версіях, а також бути в курсі змін, які вносяться та дискусії, які там проводяться. Тепер, якщо якийсь любитель systemd розуміє технічний аспект того, про що я говорю, і я вкладаю свої посилання (здебільшого посилання на systemd git repo), і навіть не здатний бачити реальність, це лише дозволяє мені думати, що я продаю це в їх очах і екстремізм у їхньому погляді / мисленні / почутті / любові / прославленні / похвалі / поклонінні systemd настільки великий, що не має значення, навіть якщо сам Лінус викине **** з systemd, вони будуть все ще закріплюватися в своїх ідеях про те, що вони правильні.
Привіт! Я не дуже експерт, і мені хотілося б знати, для чого призначений цей "systemd" і чому про нього так багато говорять, у чому проблема і яка альтернатива? Дякую
Коментар SynFlag! Я від "гіків", "гіків" та "про linuxeros" до того самого.
І це майбутнє, яке нас чекає; Убунту навіть у супі; Ноутбуки Linux просто отримують доступ до Steam і грають в останню гарячу гру. І легіони маленьких виродків, які не знають, про що йде стручок.
Приписка: фонова концепція systemd відмовна.
кнопки adk та форум не видно на головній сторінці
Отже, за даними @SynFlag, тепер усі, хто не є антисистемним, є n00b, екстремістським релігійним фанатиком та пошестю, яка корумпує GNU / Linux. З такою вузькою думкою, я не знаю, чи варто цю тему обговорювати. Краще пустити воду, і в довгостроковій перспективі станеться те, що має статися.
Це правда, настає момент, який більше не можна обговорювати. лише час покаже нам, чи буде sytemd чимось позитивним для світу вільного програмного забезпечення чи ні.
Це також дає мені уявлення, що якщо цей дистрибутив на основі debian, який не збирається використовувати systemd, стане реальним, це допоможе заспокоїти духу тих, хто не хоче нічого знати про systemd.
як коли з'явився gnome 3 і був створений величезний опір, поки не з'явилася кориця та єдність, що дозволило продовжувати використовувати програми gnome на робочому столі з більшою кількістю конфігурацій та дизайном, більш продуманим для ПК і не стільки для дотику
Можливо, це, Роло (поява Девуана), може бути пунктом консенсусу. Я думаю, що нам усім це потрібно, щоб містити поляризоване та войовниче середовище для обговорення. Devuan буде простором для створення та безперервності способу поведінки, що допоможе заспокоїти духів. Процес, який ми прожили в Debian, був болісним, проте ми мусимо зіткнутися з ситуацією, немає іншого вибору, окрім як прийняти розлуку. У підсумку це трохи нагадує розлучення. Ця вилка може бути стенограмою мирного договору та його частиною. Були альтернативні варіанти, звичайно, Slackware, Gentoo, Funtoo, Crux, ОС PCLinux, тепер Манджаро (якщо назвати декілька) ... але сцена "deb" вимагала альтернативи без systemd. Здається очевидним, що ніхто не збирається нікого переконувати, аргументи наведені за столом, і консенсусу немає (незважаючи на те, що systemd має хороші ідеї та небезпеки, які несе це програмне забезпечення очевидні). Настав час розщедритися і отримати свободу для користувача (адже це стосується Безкоштовного програмного забезпечення, так?).
Одним із факторів, що впливає на процес, було відчуття "розчарування" з боку деяких з нас, хто довіряє Debian. Ось чому Devuan представлений як виделка, а не похідне. Існує напруга, бо нікому не подобається те, що сталося; ні просистемних (звідси певні люті атаки, які намагаються наклепити), ні антисистемних (які вибрали форк). В оточенні є "скільки таланту ми можемо втратити?", Як з одного боку, так і з іншого.
Усі користувачі Debian дивляться на дистрибутив певним чином (це можна застосувати і до інших дистрибутивів). Є ті, хто захоплюється його технічною якістю, інші соціальним контрактом, його впливом у світі Linux, повагою, яку він накопичував протягом багатьох років, стабільністю у критичних виробничих середовищах ... У деяких користувачів це сприйняття змінилося, і з'явилося розчарування . Розчарування, розчарування, називайте це як хочете. Звідти до поділу є лише невеликий крок.
Розлучення з Debian схоже на те, що сталося з NetBSD та OpenBSD. Хоча час покаже. Я бачу багато сподівань у вилці, і це змушує мене думати, що це не буде швидкоплинним і стерильним розподілом. Щойно сьогодні один із членів команди гномів коментував список розсилки Девуана (хоча він робив це незручно), це, на мій погляд, свідчить про те, що Девуан викликає інтерес і хоче, якимось чином, до діалогу.
У всякому разі, гарних вихідних.
@rolo
Сказати, що відео можна обдурити або програмне забезпечення є цілковитою помилкою та образою, у своєму житті PU ** я обдурив щось, щоб створити міф, ніколи, я не хвалюсь, що бачив цю невдачу своїми засобами, а не своїми трюками. Вони всі йдуть на ****, ніж *****, і я не буду вкладати більше в системні дебати, тому що це абсолютно неправильно, ніхто нічого не хоче розуміти, і все це як релігія, яку, я ненавиджу , бо все це за догматом віри. Будьте задоволені системою.
@SynFlag насильство бреше
Це відео демонструє хибність твердження, що якщо один із модулів systemd зруйнований, це призводить до аварійного завершення systemd, оскільки, очевидно, з того, що ваше відео показує, що не сталося, xddddd і, до речі, журнал працює як root, тому, якщо третя сторона входить і зловмисно вибиває двійковий файл журналу, я б не турбувався про systemd, а про безпеку вашого комп'ютера. xdddddd. Нарешті, щодо теми відео, повторіть те, що показано, редагуючи за допомогою файлу nano /var/log/journal/24f02f5b2b16758b820ea6a751ed6efb/system.journal, і при перезапуску ви виявите, що існує нова system.journal та система @@ 24f02f5b2b16758 @ 820f6f751bXNUMXbXNUMX. Журнал, який є пошкодженим двійковим файлом.
Тобто журнал усвідомлює, що файл пошкоджений, тому він не перейменовує його і знову створює новий, я не бачу, в чому проблема ?, Те саме, що якщо файл system.journal видалено, журнал повертає його для створення.
Цікаво, що сталося б, якби я зіпсував файл простого текстового журналу за допомогою шістнадцяткового редактора, безумовно, поки ви не зрозумієте, що файл пошкоджений, усі дані будуть знищені
Поговоримо трохи про журнал, який є однією з найпоширеніших дорікань systemd.
journal - це дуже важливий компонент systemd, який фіксує повідомлення Syslog, повідомлення журналу ядра, оперативну пам'ять та початкові повідомлення про завантаження, а також повідомлення, написані в STDOUT / TDERR, і робить всю цю інформацію доступною для користувача.
Але найголовніше, що журнал може використовуватися паралельно або замінити традиційний демон системного журналу, такий як rsyslog або syslog-ng, тому обережний системний адміністратор може мати rsyslog або syslog-ng як другий інструмент запиту, окрім перетворення записів журналу у звичайний текст на випадок, якщо двійковий файл пошкоджений
Іншим важливим фактом щодо журналу є те, що якщо папка / var / log / journal не створена, інформація зберігається лише тимчасово, яка втрачається при кожному перезапуску.
наприклад, коли я ввів systemd у debian, збереження журналу не було активним, тому мені довелося вручну створити папку журналу
http://0pointer.net/blog/projects/journalctl.html
Ті, хто знає англійську, не можуть пропустити переговори, що відбуваються між розробниками devuan, jaromil dimkr max2344 серед інших на IRC-каналі #devuan.
Дуже весело читаючи дослідження системного коду, оскільки вони спеціально розповсюдили його, щоб заразити (створити непотрібні залежності).
Systemd мене дратує ... прямо вперед ... це важко. Мало документації, ані чортовий тонкий запуск не виконує лише KDM або gdm, а в легкій системі я хочу, щоб slim lxdm не підтримував його та не компілював… .. Серйозно, навіть раніше… я був задоволений, що вони повинні. Правда в тому, що я почав використовувати openrc, як кажуть у gentoo, і це допомогло…. Багато
@rolo
Ви нахабний і викривлювач новин, щоб сказати це. Це найгірша образа, коли ти кажеш мені, що я брешу або фальсифікую дані, мене справді огидно, як для того, щоб захищати щось, ти нападаєш на людей, які роблять такі серйозні заходи, як я. Журнал пошкоджений, система аварійно завершує роботу, перезапуск служби не працює, тому немає іншого вибору, окрім як перезапустити машину, що не найкраще на зламаному сервері, ви збираєтесь сказати мені, що якщо безпека була порушена, найкраще - це перезапустити або перевстановити, і це єдине, про що мені слід турбуватися, оскільки системники кажуть, що виправдовуються, а не роблять гарячий аналіз ЩО СТИЛИСЯ? щоб дійти до цього пункту? Очевидно, що ви є ще одним продуктом нового системного адміністратора, якщо ви потрапите до того, який був піднятий за допомогою ubuntu і має захист DOS 5.0 на вашому ПК, так що те, що ви кажете, я сприймаю як те, від кого воно походить, мене турбує, що ви сумнівайтесь також Той, хто фальсифікує - це ви, чи відповідали ви тій самій ОС оновленнями ТОГО дня? Звичайно, ні, тому спробуйте збрехати іншому. Якої нестачі є у вас, ідіть працювати таксистом більше, ніж я сумніваюся, що це вам дасть, припиніть грати з Linux і продовжуйте шукати pr0n
Подивимось голуб (synflag), тато покаже вам, як змусити журнал продовжувати працювати після того, як наш журнал двійкового журналу з якихось причин пошкоджений, без необхідності перезавантажувати комп'ютер.
У цьому прикладі ми починаємо з базової інсталяції 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
#ls
24f02f5b2b19808b820ea0a980ed6efb
# cd 24f02f5b2b19808b820ea0a980ed6efb
# nanosystem.journal
### тепер ми модифікуємо деякий рядок файлу, щоб імітувати його пошкодження
#journalctl
### як очікувалося, нічого не відбувається
#### Чи потрібно перезавантажувати комп'ютер, щоб журнал створив новий двійковий файл? НІ
# systemctl примусово перезавантажити systemd-journal.service
#ls
system@24f02f5b2b19808b820ea0a980ed6efb-0000000000000001-0005069a53abf581.journal
система.журн
#journalctl
### Як ми бачимо, журнал створює новий двійковий файл журналу, і тепер ми можемо знову отримати доступ до інформації, не перезавантажуючи комп'ютер у будь-який час
https://www.youtube.com/watch?v=hEagyMdkN4A&feature=youtu.be
висновок: synflag або ти невіглас, або ти казкар
нехай гарнірує вас кінцевим
для помилки друку та зловживання копіюванням та вставленням я написав systemd-journal.service, коли насправді послуга називається systemd-journald.service
Пічхон?, ... як ти помиляєшся худий, серйозно .. Я це вже знав, повідомляй про помилку в червоному капелюсі, щоб побачити, що вони сказали, я наберу відповідь, подивлюсь, чи ти зловив:
Якщо ви видалите вихідний файл або перезапишете частини файлу, демон насправді нічого з цим не зробить: якщо зловмисник має дозвіл на модифікацію вихідного файлу, він уже переміг. Демон міг перевірити деякі з цих речей, але це було б досить неефективно і не дуже корисно для чогось. Якщо ви хочете, ви можете встановити періодичний криптографічний підпис за допомогою 'journalctl –setup-keys'. Див. Сторінку керівництва journalctl.
Journalctl залежить від rsyslog, він не перезапускається у разі помилки в журналі, яка rsyslog не потрібна, загалом, вам потрібно використовувати fordward, щоб відправити rsyslog, і таким чином він пишеться, незважаючи на все, і журнал журналу регенерується, це конструктивна вада журналу, якщо ви не хочете його бачити, підірвіть мене.
@rolo
У відео (я не знаю, чи зробили ви це) я бачу, що на хвилині 2:11 використовується ls, а не ls -l, що дозволить побачити розмір, який спочатку мав файл system.journal, потім вони редагують його за допомогою nano та додайте порожні рядки, перезапустіть службу вручну, і на хвилині 3:15 вони знову роблять ls, а не ls -l, потім на хвилині 3:20 вони бачать журнал з journalctl, це показує поточний журнал, який чудовий.
Тепер приходьте мої запитання:
1 - оскільки використовується ls, а не ls -l, щоб побачити вихідний розмір журналу перед редагуванням
2 - що сталося зі старим зрубом? куди systemd помістив його до пошкодженого двійкового журналу?
3 - за допомогою якої команди systemd ви можете відновити пошкоджений двійковий журнал ... який ви не повинні видаляти
привіт
@anonymous
Тепер приходьте мої запитання:
1 - оскільки використовується ls, а не ls -l, щоб побачити вихідний розмір журналу перед редагуванням
2 - що сталося зі старим зрубом? куди systemd помістив його до пошкодженого двійкового журналу?
3 - за допомогою якої команди systemd ви можете відновити пошкоджений двійковий журнал ... який ви не повинні видаляти
1 правда, що я не думав про це, просто використовуйте ls, щоб побачити, які файли були в каталозі, але якщо вам цікаво, ви можете його відтворити, процедура детально описана, і я роблю це у віртуальній скриньці (встановлення бази debian є шматок пирога)
2 старий журнал залишається в тому ж каталозі, лише systemd перейменовує його з набором цифр і букв (показано у відео)
3 У будь-якому випадку, ви можете спробувати використовувати сторонні програми (певний шістнадцятковий редактор, я гадаю), оскільки якщо systemd може відновити пошкоджений файл, він не перейменовує його або створює новий. У будь-якому випадку, і, як я вже згадував в інших випадках у цій публікації, обережний системний адміністратор може використовувати rsyslog або syslog-ng як другий інструмент запиту, крім перетворення записів журналу у звичайний текст, якщо двійковий файл пошкодиться.
Я маю на увазі, це не ідея переконувати кого-небудь використовувати systemd (мені навіть сподобалося б, що у програмі встановлення debian є можливість вибрати int). але я не збираюся мовчати, коли читаю невігласів чи казкових, які постійно повторюють брехню про systemd, як існує блог, коли бачиш, що ці вислови не збігаються з реальністю. і як сказав Арістотель, єдина істина - це реальність 😉
@rolo
Я ще раз подивився відео, і якщо воно там було перераховане, лише числове ім’я було таким довгим, що я його бачив, я думав, що це каталог ... Суверенне ім’я.
Щодо відновлення двійкового файлу, так, логічно, що ви говорите ... якби я міг його відремонтувати, я б не створював нового.
Нарешті, я залишаюся з тим, що це не повинен бути двійковий файл, щоб цього не сталося, і щоб я міг бачити це без спеціальних інструментів з 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 зазнав аварії через збій журналу, але насправді є перевірка введення двійкового файлу (який використовується в режимі реального часу) за допомогою текстового редактора, я також уточнюю, що всі тести що я виконував, ніколи не перевіряв віртуальну машину. По-друге, ніхто при здоровому розумі не може стверджувати, що Linux не позначається як xddd,
Fabler?, Худий, трохи стримайся, fabler твоя стара, яка каже, що я кидаю гуму, коли не чіпаю її палицею, повертаюсь до поваги:
1. - Ви повинні перезапустити або примусити перезапустити службу, що не ідеально, і в CentOS 7, коли я спробував перезапустити службу, нічого не зробив, не забувайте, що це версія 208, а не нова 217 або 216 Fedora.
2.- Невідповідні і ті, хто повідомляє про помилки? ... ти ідіот, я тобі навіть не відповідаю
3.- НЕЩАСЛИВИЙ, версія, яку я спробував того дня відео, яку ви бачите, вся ОС розбилася, чому ви думаєте, що орто нещасна брехня? Я не брехня-мавпа, піти взяти синдр-паджеро.
4. - Це залежить від саморегенерації, він не робить цього сам, насправді я запропонував це systemd розробникам як особливість, що вона регенерує себе, не зупиняючи реєстрацію, якщо служба не перезапущена, вони прийняли це як те, що вони повинні додати, то смокчіть мій член і скажіть мені спасибі таточку за співпрацю, поки я дивлюся порно.
До побачення худий, мені набридло розмовляти з мавпами, бо я волію ходити в зоопарк, коли ти перебуваєш на рівні мого заднього проходу, ми спілкуємось.
@SynFlag Прошу вибачення, я не знав, що ти хворий, я справді думав, що ти казковий і невіглас, але з того, що ти щойно написав, розумію, що ти насправді мареш.
ну нічого, сподіваюся, ви краще закінчите ліки і повернетеся до реальності, змушуйте! ти можеш!!!
Я читав, читав і перечитував, але нічого не розумію, знаю лише, що з часу виходу Xubuntu 14.04.1 у мене не виникало жодних проблем ні з ноутбуком, ні з лазерним принтером hp 1102, я не знаю взагалі що-небудь, я користувач, і я не знаю, якщо systemd гірший чи не підходить від init, але я повторюю, у мене немає проблем з xubuntu. 🙂
Я читаю, читаю і перечитую, і я просто знаю, що я переживаю стару тему. XD