euthanasepam | Йойтішно-технічне: Without Systemd Wiki

В основі філософії юніксу лежить, по суті, одна-єдина фундаментальна ідея старої чудової Computer Science: keep it simple (KISS). Все має бути якомога простішим та зрозумілішим. Стартові та адміністративні скрипти мають бути у формі, яку спроможна прочитати й зрозуміти жива людина. Тому й традиційні прикладні програми теж так влаштовано. Якщо чогось не розумієш, то береш текст тої програми і читаєш до дзену. Оця прекрасна витончена досконала філософія вільного та відкритого до знань суспільства, однак, «чомусь» виявилася несумісною з так званим індустріальним виробництвом програмного забезпечення. Тому й маємо тепер, зокрема, бравзери, що потребують гігабайтів пам’яті для відображення мізерної кількості корисної інформації. Такі абсурдні речі постають в результаті діяльності в інтересах прибуткового «індустріального програмування», що за голову хапаєшся.

> Стартові та адміністративні скрипти мають бути у формі, яку спроможна прочитати й зрозуміти жива людина.

але саме цим systemd людям і подобається! ггг

щоб зрозуміти як працює конкретний юніт, у systemd-based дістро не потрібно навіть знати sh. там примітівні logic-less .ini файли. всю magic (як automatic dependencies, яку я обожнюю) systemd робить сам.

за це його і люблять.

Якщо в мене в маку або віндовсі щось ламається, то я маю від системи повні торби журналів, які зазвичай майже ні про що змістовне не кажуть, бо нема у відкритому доступі викладу сутності таких проблем, а самі журнали призначено для фахівців вендора, окрім яких майже ніхто в світі не знає, що насправді трапляється в системі під час таких подій. Вертаючи до раніше сказаного: якщо супроводом системи займається вендор, то systemd, launchd і таке інше мають сенс. Але якщо я сам собі адмін свого локалхосту, то мені від непередбачуваних «подій» стає трохи боляче, бо я не можу самотужки виправити проблему, я навіть локалізувати її часом не можу.

якщо користувач неспроможний прочитати journalctl(1) і systemd(1), ніякі милі серцю sysv скрипти йому локалізувати проблему не допоможуть.

якщо deamon X гепався у sysv env і гепається у systemd one, то systemd хочаб відфільтрує необхідну інфо і не буде намагатися запускати інші юніти, які залежать від дефективного X.

з sysv у таких випадках--you're on your own.

Та ж теє — якщо раніше гепалися ікси, то в журналах елементарно було знайти, що їх гепнуло, і виправити. На моїй пам’яті не було, щоб ікси гепнули всю систему. В чому тут переваги systemd?

Інший нюанс, за який лаяли sysv — що вона все запускає по черзі. От вже скільки років я не второпаю: чим це було погано, яку це створювало нездоланну проблему? Ну не 20 секунд запускався комп’ютер, а 40. Було би тільки такого лиха в житті…

> На моїй пам’яті не було, щоб ікси гепнули всю систему

я не мав на увазі x11, символ X--то був a placeholder.

> Інший нюанс, за який лаяли sysv — що вона все запускає по черзі.

прочитайте systemd(1) про типи dependencies, як воно калюкулює вихідний dependency graph. паралельний запуск--то лише побічний продукт.

От поясніть раціонально старому шанувальнику теплого лампового юніксу, що доброго і корисного дає systemd решті світу, крім RH і деяких девелоперів?

ми йдемо на 3те коло.

я кажу "стало простіше", бо замість купи імперативних half-assed скриптів ми маємо простий декларативний DSL. так, звичайно, щоб зрозуміти той DSL треба почитати документацію по systemd.

з'явилися інструменти типу systemd-analyze, які було дуже тяжко писати для sysv world.

девелоперам і pkg maintainers стало простіше писати і підтримувати сервіси і packages.

у девелоперів з'явилися космічні capabilities порівняно з sysv init: контеринізація сетевих демонів.

адміністраторам стало легше виявляти проблеми з сервісами, бо journalctl показує все на як на долоні без зайвого сміття, а система dependencies дозволяє моментально побачити який сервіс що потребує або провайдить.

адміністраторам стало простіше to override настройки конкретних сервісів без редактування системних файлів: юзерськи настройки з /etc/systemd мержаться з системними read-only /usr/lib/systemd/.

Ви кажете (я трохи саркастично підсумовую, no offence please) "я люблю старий ламповий юникс, абстрактний KISS, Айнштайна і читати borne shell у /etc".

от така дискусія :(

Edited (typos) 2017-04-25 12:07 (UTC)

То це ж вам стало простіше, я про це й кажу. А мені, себто пересічному юзерові, сяйнула раптова думка дропнути пінгвіна (який мені був дуже припав до вподоби майже два десятиліття тому), бо його перспективу бачу сумною та невтішною.

ага, righty-oh. тобто, не всім стало погано.

а хтось тут спочатку храбро писав:

"[systemd] Принципово не потрібне. І варто сказати навіть більше: та мета, для якої зробили systemd — вона також трохи кульгава на здоровий глузд."

принципово! бггг

а ще мені знається, що Ви не є пересічний юзер, бо пересічним нічого крім бовзера не потрібно.

Саме так — принципово. Оце я пишу сього комента з мака, в якому давно реалізовано все те, що намріяли хлоп’ята з Редхату. І аналог systemd є (launchd), і базова юніксова система під капотом, і всілякі інтерпретатори, і шелли, і засоби програмування — усе є. А зверху на тому ще й чудовий десктоп з фотошопами та іншими принадами. Навіщо потрібен позбавлений свободи й залежний від конкретних комерційних компаній лінукс, пофарбований на щось подібне до мака чи віндовса, якщо вже є мак та віндовс, кожен locked-in на свого вендора?

>> а ще мені знається, що Ви не є пересічний юзер, бо пересічним нічого крім бовзера не потрібно.

Це несуттєві деталі, гг.

> позбавлений свободи

злий RH змінив ліценцію на Fedora?

(no subject)

euthanasepam - 2017-04-26 07:38 (UTC) - Expand

(no subject)

henry_flower - 2017-04-26 10:17 (UTC) - Expand

В скриптах стилю sysv все написано in plain text: роблю оце, далі роблю оте, якщо це так, то те буде так. Юзер може піти в /etc і прочитати в усіх деталях, що, коли, де і як робить система та програми. І логіка цієї роботи не прихована, а відкрита. Так само в звичайному тексті логи. Скажімо, для мене це має значення.

нічого "прихованого" у роботі systemd нема. ніяких юзерів, читаючих /etc не існує. якщо би вони існували, то я не розумію як може подобатися читати 50-200 lines of sh code (повного наївних assumptions) на кожен сервіс vs. 5-20 lines of .ini files.

>> нічого "прихованого" у роботі systemd нема.

Пропоную не вдавати, наче ми не розуміємо різниці між бінарним і текстовим форматами.

>> ніяких юзерів, читаючих /etc не існує.

З чого ви це взяли? Може десь RH пише таке в своїх полум’яних релігійних методичках і промовах, але є люди, які часом зазирають до /etc і навіть там щось пишуть руками, а відтак потребують текстових файлів, притомно коментованих.

>> якщо би вони існували, то я не розумію як може подобатися читати 50-200 lines of sh code (повного наївних assumptions) на кожен сервіс vs. 5-20 lines of .ini files.

Мені, наприклад, потрібна очевидна й доступна логіка роботи системи, а не ще одна додаткова надбудова зверху над капотом. На мою думку, runlevels це чудовий винахід для розумного та гнучкого керування своєю системою.

взагалі, це якийсь дуже товстий тролінг, ггг

як sysv допоможе мені to replicate

ReadWritePaths=, ReadOnlyPaths=, InaccessiblePaths=
PrivateTmp=
PrivateNetwork=
ProtectHome=
SystemCallFilter=

?

я не кажу навіть про IOScheduling* і CPUScheduling*. (всі опції з systemd.exec(5))

в останніх версіях systemd з'явилась опція RootImage=. це uber cool!

Ви подумки намагаєтесь порівняти навіть не ровер, ні, ви намагаєтесь порівняти самокат з машиною, ггг

Ви це кажете з позиції девелопера, якому нема радості копирсатися в різних дистрибутивних реалізаціях запуску системи і її сервісів. А я на цю проблему дивлюся з точки зору advanced user, який сам собі адмін, автор прикладних скриптів і таке інше. Мені геть байдуже, чи буде система запускатися на 10 секунда швидше, бо вона в мене або робить 24/7, або вимкнена, флешку я монтую руками, а на оптичні диски пишу з консолі. Розумієте? Але якщо в мене забирають flexibility канонічного юніксу, то я просто викину геть з машини таку систему і знайду іншу. Бо якщо вже так трапилось, що для мене sysvinit вже нема, то я оберу аж ніяк не лінукс, який потугами піонерів уже двадцять років намагається стати віндою та маком, а справжній мак та вінду (які, до речі, й так маю), або соляріс чи якусь bsd, або дебіан з ядром bsd тощо.

>> взагалі, це якийсь дуже товстий тролінг, ггг

Такий товстий, що я аж зніс оце лінукса, який в мене кочував з машини на машину року десь з 2005-го.

> В основі філософії юніксу лежить, по суті, одна-єдина фундаментальна ідея старої чудової Computer Science: keep it simple (KISS)

a nitpick: the KISS principle--інженерний, а не CS. CS та (софтверна) інженерія ортогональні.

— Здраствуйтє, дєвачькі! Приїхали, гг.

Це загальний принцип науки, і CS також, і інженерний також. Можете погуглити міркування Ейнштейна з цього приводу, якщо мені не вірите. Доки люди цього принципу дотримувались, системи й програми були маленькими та швидкими, а як від цього принципу відцуралися, то рясно вродились пітони, хроми, гноми та інше неподобство, що дурно жере всі ресурси комп’ютерного причандалля.

CS цє https://cs.stackexchange.com/

практичного там ~0. ніякий KISS іх не хвилює.

unix philosophy це інженерія, а не наука: http://www.catb.org/~esr/writings/taoup/html/ch01s07.html

міркування Ейнштейна (чи будь якого іншого фізика) про computer science мене не цікавлять.

> системи й програми були маленькими та швидкими

МИКОЛА ГНАТОВИЧ
Раніш люди ніколи не умивалися. І їли сало. А захоче помидора чи
диню--то так зірве, навіть і не миє. І от таки в усіх пики були!

пардон, не втримався, ггг

Edited 2017-04-25 10:48 (UTC)

Усяка інженерія (як прикладна діяльність) має тата й маму — розум та науку.

>> CS цє https://cs.stackexchange.com/

Я таке не читаю, перепрошую. А отаке — залюбки: http://cs2.ist.unomaha.edu/~stanw/171/csci4500/UNIXProgrammingEnvironment.pdf

то дуже гарна книжка для newbies.
ніякого стосунку до CS вона не має.

На таке просто нема що відповісти.