З кожним днем наші комп'ютери стають дедалі важливішою частиною нашого життя; якщо з ними виникають якісь проблеми, це впливає на наш настрій, наш гумор, ха-ха. Звичайно, користувачі Windows більш схильні до панічних атак: віруси ( хай живе Linux! ), дефрагментація жорсткого диска, пошук та встановлення Clean Master для ПК ( хоча тут, у Linux, нам також потрібно очистити систему; BleachBit — одна з найкращих альтернатив ). Останнім часом деякі користувачі Linux відчувають певний головний біль під назвою systemd.
У будь-якому разі, щоб перейти до суті, я прочитав цікаву статтю про systemd , який, здається, зараз дуже популярний.
Systemd , який деякі вважають ( і я скористаюся словами друга ) «одним кільцем, яке керує всіма »... для інших, яким це просто байдуже; доки комп'ютер працює належним чином, їм байдуже, чи виконує init X чи Y, чи використовується systemd. Що ж до мене, ну... скажімо так, я надаю перевагу init; мені він простіший.
Я залишаю статтю тут:
Перш ніж я почну, мушу сказати, що мені дуже не подобається рішення щось змінити в Debian, але я не маю наміру відмовлятися від моєї улюбленої спіралі. Я просто намагаюся переконатися, що якщо ми збираємося обговорювати якусь тему, ми робимо це якомога краще підготовленими, хоча я сам не вважаю себе прихильником systemd. Щоб розвіяти міфи про systemd, я спиратимуся на веб-сайт, де розробники діляться своїми поглядами , який потрапив до моєї уваги завдяки колегі, який, здається, є прихильником systemd, хоча він не є користувачем Debian. З огляду на це, я думаю, що можу спробувати розвіяти міфи про те, що говорять про systemd.
systemd базується на двійковій системі
Можливо, це один із аспектів, який шокує нас найбільше, якщо все базується на двійковій системі, як ми можемо відстежувати те, що зазвичай робимо за допомогою журналів? Я не уявляю, як цей міф народився, але це не зовсім так.
systemd конфігурується майже виключно через текстові файли. Деякі параметри, які також можна змінити за допомогою командного рядка ядра та змінних середовища. У вашій конфігурації немає нічого двійкового (навіть XML). Просто простий, зрозумілий та легкий для читання текстовий файл.
Ця річ монолітна, і вона контролює все
Перш ніж потрапити на згаданий веб-сайт, я зізнаюся, що сам думав так, але, прочитавши те, що говорять його розробники, моя думка щось змінила ...
Якщо ви збираєте systemd з усіма ввімкненими параметрами конфігурації, ви збираєте 69 окремих бінарних файлів . Ці бінарні файли виконують різні завдання та ретельно розділені з низки причин. Наприклад, systemd був розроблений з урахуванням безпеки; тому більшість демонів працюють з мінімальними привілеями (наприклад, використовуючи можливості ядра) та відповідають лише за дуже специфічні завдання, мінімізуючи їхню поверхню безпеки та вплив. Крім того, systemd паралелізує завантаження більше, ніж будь-яке попереднє рішення. Ця «паралелізація» створюється шляхом паралельного запуску кількох процесів . Таким чином, очевидно, що systemd дуже добре розділений на безліч бінарних файлів і, отже, процесів. Фактично, багато з цих бінарних файлів настільки добре розділені, що вони дуже корисні поза systemd.
Пакет, що містить 69 окремих бінарних файлів, навряд чи можна назвати монолітним. Однак, відмінність від попередніх рішень полягає в тому, що ми постачаємо більше компонентів в одному tar-архіві та зберігаємо їх разом в одному репозиторії з єдиним циклом випуску.
Це не схоже на 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; ви можете запускати скрипти, написані будь-якою мовою, як служби systemd, оскільки systemd зовсім не хвилює, що знаходиться всередині вашого виконуваного файлу. Більше того, ми широко використовуємо скрипти оболонки для власних цілей: для встановлення, збірки та тестування systemd. І ви можете вставляти скрипти в процес раннього запуску, використовувати їх для звичайних служб, запускати їх під час остаточного завершення роботи — практично немає обмежень.
На цьому етапі, я вважаю, деякі з основних переконань, можливо, прояснилися. Хоча я не вважаю себе прихильником змін і маю застереження щодо ідеї « одного демона, який править усіма », я думаю, що зрештою ніхто не наважиться сказати, що це взагалі не працює. Я навіть знаю деяких користувачів, які помічають, що з systemd «ПК працює швидше», але це вже тема для окремого обговорення. Наразі я можу лише запросити вас обговорити ваші точки зору тут щодо системи ініціалізації, яку прийняли багато дистрибутивів, хоча найсильніші реакції зараз спостерігаються в спільноті Debian, яка навіть породила новий форк через усе це. Подобається вам це чи ні, це ваша особиста справа; зі свого боку, я просто хочу зробити свій внесок у розвінчання міфів про systemd, який зрештою буде присутній у Jessie, наступній стабільній версії Debian.
Я бачив статтю про GUTL (яка, у свою чергу, була взята з DesdeAbreus )
Системний струм?
Я один із тих, хто не читає багато новин, коли щось викликає стільки суперечок, я вважаю за краще зупинитися на технічних деталях. Справа в тому... Іноді я відчуваю, що певні теми перестають бути суто технічною дискусією чи дискусією, а стають схожими на плітки шоу-бізнесу
Спочатку відкрита тирада від користувача про systemd під назвою systemd VS intelligence , потім Лінус Торвальдс заявив, що systemd не такий вже й поганий , як його зображують ( і він має рацію ), форк під назвою useledd ... без коментарів... і, коротше кажучи, нарешті Devuan.
Не скажу, чи це так погано, як кажуть, менш погано чи гірше. Система працює добре для мене, проте особисто я б віддав перевагу init, оскільки мені подобається його спосіб організації різних речей (наприклад, журналів). Але якщо systemd називатимуть скаковою конячкою і доведеться замінити init ( чи буде він нашою робочою конячкою, яка робитиме все, але повільно? ), ну... якщо зміни не будуть надто радикальними, користувачі зможуть адаптуватися без особливих проблем, і система працюватиме краще (так, краще, можливо, цього буде недостатньо для мене!), тоді ласкаво просимо! 😉