Всеки ден компютрите ни стават все по-важна част от живота ни; ако имат някакъв проблем, това се отразява на настроението ни, на хумора ни, хаха. Разбира се, потребителите на 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 отделни двоични файла, трудно би могъл да се нарече монолитен. Това, което се различава от предишните решения обаче, е, че ние доставяме повече компоненти в един tarball и ги държим свързани заедно в едно хранилище с унифициран цикъл на издаване.
Това не прилича на Unix
В това със сигурност има известна истина. Изходните файлове на systemd не съдържат нито един ред код от оригиналните UNIX редове. Вдъхновението обаче се извлича от UNIX и по този начин има много UNIX в systemd. Пример за това би била идеята на UNIX „всичко е файл“, която се отразява в това, че в systemd всички услуги са изложени по време на изпълнение във файлова система на ядрото, cgroupfs. И така, една от оригиналните функции на UNIX беше поддръжката на няколко места, базирана на вградената поддръжка на терминали. С systemd отново донесохме поддръжка за много места, но този път с пълна поддръжка за днешния хардуер, покриващ графики, мишки, аудио, уеб камери и други. Всъщност дизайнът на systemd като набор от интегрирани инструменти, всеки от които има своите индивидуални цели, но когато се използват заедно, е повече от сумата на частите, което е горе-долу в основата на философията на UNIX. Така че начинът, по който се работи с нашия проект (т.е. поддържането на по-голямата част от ядрото на операционната система в едно git хранилище) е много по-близо до модела BSD (който е истински UNIX, за разлика от Linux) за да се свършат нещата (където по-голямата част от основната операционна система се съхранява в едно CVS / SVN хранилище), което никога не е било така в Linux.
В крайна сметка въпросът дали нещо е UNIX или не е от голямо значение. Тъй като е технически отличен, едва ли е уникален за UNIX. За нас UNIX е важно влияние (всъщност най-голямото), но имаме и други влияния. Следователно в някои области systemd ще бъде много UNIX, а в други малко по-малко.
Това е много сложно ...
В това със сигурност има известна истина. Съвременните компютри са сложни зверове и операционната система, която работи на тях, очевидно също ще бъде, така че те трябва да бъдат сложни. Въпреки това, systemd със сигурност не е по-сложен от предишните имплементации на същите компоненти. Това е по-просто и има по-малко излишък. От друга страна, изграждането на проста системна операционна система ще включва много по-малко пакети от традиционната употреба на Linux. По-малкото пакети улеснява изграждането на вашата система, отървава се от взаимозависимости и голяма част от различното поведение на всички участващи компоненти.
Това не ми позволява да използвам скриптове на черупки
Това е напълно невярно. Ние просто не ги използваме за процеса на зареждане, защото смятаме, че не са най-добрият инструмент за тази конкретна цел, но това не означава, че systemd е несъвместим с тях. Можете лесно да изпълнявате shell скриптове като systemd услуги или демони; можете да изпълнявате скриптове, написани на всеки език, като systemd услуги, тъй като systemd изобщо не се интересува какво има във вашия изпълним файл. Освен това, ние широко използваме shell скриптове за наши собствени цели: за инсталиране, изграждане и тестване на systemd. И можете да поставите скриптовете в процеса на ранно стартиране, да ги използвате за нормални услуги, да ги стартирате при окончателното изключване - практически няма ограничения.
В този момент предполагам, че някои от основните вярвания може би са изяснени. Въпреки че не се смятам за привърженик на промяната и имам своите резерви относно идеята за „ един демон, който да управлява всички “, мисля, че в крайна сметка никой няма да посмее да каже, че това изобщо не работи. Дори познавам някои потребители, които забелязват, че със systemd „компютърът работи по-бързо“, но това би било друг въпрос за обсъждане. Засега мога само да ви поканя да обсъдите вашите гледни точки тук относно init системата, която много дистрибуции са възприели, въпреки че най-силните реакции в момента се наблюдават в общността на Debian, която дори породи нов fork заради всичко това. Дали ви харесва или не, е личен въпрос; от моя страна просто искам да направя своя принос, за да демистифицирам systemd, който в крайна сметка ще присъства в Jessie, следващата стабилна версия на Debian.
Видях статията за GUTL (която от своя страна е взета от DesdeAbreus )
Systemd ток?
Аз съм от онези, които не четат много новини, когато нещо предизвиква толкова много спорове, предпочитам да остана с повече технически подробности. Работата е там.... Понякога чувствам, че определени теми престават да бъдат чисто техническа дискусия или дебат и стават като една от онези клюки в шоубизнеса
Първо, открита тирада от потребител за systemd, наречена systemd VS intelligence , след това Линус Торвалдс, който казва, че systemd не е толкова лош , колкото го представят ( и той е прав ), fork, наречен useledd ... без коментари... и накратко, накрая Devuan.
Няма да кажа дали е толкова лошо, колкото се казва, по-малко лошо или по-лошо. Системата работи добре за мен, но лично аз бих предпочел init, тъй като харесвам начина, по който организира различни неща (като например лог файлове). Но ако systemd ще бъде наричан състезателен кон и трябва да замени init ( дали ще бъде нашият работен кон, правещ всичко, но бавно? ), е, стига промяната да не е твърде драстична, потребителите да могат да се адаптират без много проблеми и системата да работи по-добре (да, по-добре, може би това няма да е достатъчно за мен!), тогава я приветствайте! 😉