Számítógépeink napról napra egyre fontosabb részét képezik életünknek; ha bármilyen probléma adódik velük, az kihat a hangulatunkra, a humorunkra, haha. Természetesen a Windows-felhasználók hajlamosabbak a pánikrohamokra: vírusok ( éljen soká Linux! ), merevlemez-töredezettségmentesítés, a Clean Master for PC megtalálása és telepítése ( bár itt Linux alatt is meg kell tisztítanunk a rendszert; a BleachBit az egyik előnyben részesített alternatíva ). Az utóbbi időben néhány Linux-felhasználó egy bizonyos fejfájást tapasztal, amit systemd-nek hívnak.
Na mindegy, hogy a lényegre térjek, olvastam egy érdekes cikket a systemd- ről , ami úgy tűnik, mostanában nagyon népszerű.
A Systemd-t , amit egyesek ( és egy barátom szavait használom ) „egyetlen, mindent uraló gyűrűnek ” tartanak... mások számára, akiket ez egyszerűen közömbös; amíg a számítógép megfelelően működik, nem érdekli őket, hogy az init X-et vagy Y-t csinálja-e, vagy hogy a systemd-t használják-e. Ami engem illet, nos... mondjuk úgy, hogy én az init-et részesítem előnyben; egyszerűbbnek találom.
A cikket itt hagyom:
Mielőtt belekezdenék, el kell mondanom, hogy nagyon nem tetszik a Debianban végrehajtott változtatások döntése, de eszem ágában sincs elhagyni szeretett spirálomat. Csupán arra törekszem, hogy ha már megvitatunk egy témát, azt a lehető legfelkészültebben tegyük, annak ellenére, hogy én magam nem tartom magam systemd-pártinak. A systemd rejtélyének eloszlatásához egy olyan weboldalra fogok támaszkodni, ahol a fejlesztők megosztják a nézőpontjaikat , amire egy kollégám révén tettem szert, aki látszólag systemd-párti, annak ellenére, hogy nem Debian-felhasználó. Ennek fényében azt hiszem, folytathatom a systemd-ről szóló állítások eloszlatását.
A systemd bináris alapú
Talán ez az egyik szempont, amely minket a legjobban megdöbbent, ha minden bináris alapú, hogyan figyeljük az általában naplókon keresztül végzett dolgokat? Fogalmam sincs, hogyan született ez a mítosz, de ez nem teljesen igaz.
A systemd szinte kizárólag egyszerű szöveges fájlokon keresztül van konfigurálva. Néhány olyan beállítás, amely a kernel parancssorával és környezeti változókon keresztül is módosítható. A konfigurációban nincs semmi bináris (még XML sem). Csak egy egyszerű, egyértelmű és könnyen olvasható szöveges fájl.
Ez a dolog monolitikus és mindent irányít
Mielőtt eljutnék a fent említett weboldalra, bevallom, hogy magam is így gondoltam, de miután elolvastam, amit a fejlesztői mondanak, a véleményem valamit megváltoztatott ...
Ha a systemd-t úgy fordítod, hogy az összes konfigurációs opció engedélyezett, akkor 69 egyedi bináris fájlt fogsz létrehozni . Ezek a bináris fájlok különböző feladatokat szolgálnak, és számos okból gondosan elkülönülnek. Például a systemd-t a biztonság szem előtt tartásával tervezték; ezért a legtöbb démon minimális jogosultságokkal fut (például a kernel képességeit használva), és csak nagyon specifikus feladatokért felelős, minimalizálva a biztonsági felületüket és hatásukat. A systemd a korábbi megoldásokhoz képest jobban párhuzamosítja a rendszerindítást. Ez a "párhuzamosítás" több folyamat párhuzamos futtatásával jön létre. Így egyértelmű, hogy a systemd nagyon jól fel van osztva számos bináris fájlra, és következésképpen folyamatra is. Valójában ezek közül a bináris fájlok közül sok annyira jól elkülönül, hogy a systemd-n kívül is nagyon hasznosak.
Egy 69 egyedi bináris fájlt tartalmazó csomagot aligha nevezhetünk monolitikusnak. Ami azonban eltér a korábbi megoldásoktól, az az, hogy több komponenst egyetlen tarballban szállítunk, és egyetlen repositoryban láncolva tároljuk őket, egységes kiadási ciklussal.
Ez nem hasonlít a Unix-ra
Ebben bizony van némi igazság. A systemd forrásfájlok nem tartalmaznak egyetlen kódsort sem az eredeti UNIX sorokból. Az inspiráció azonban a UNIX-ból származik, ezért sok UNIX található a systemd-ben. Példaként említhetjük a UNIX "minden fájl" ötletét, amely abban tükröződik, hogy a systemd-ben minden szolgáltatás futás közben van kitéve egy rendszermag fájlrendszerben, a cgroupfs. Tehát a UNIX egyik eredeti jellemzője a beépített terminál támogatásán alapuló többüléses támogatás volt. A systemd-vel ismét natívan hoztuk a többüléses támogatást, de ezúttal a mai hardver teljes támogatásával, amely grafikákat, egereket, hangot, webkamerákat és egyebeket takar. Valójában a systemd tervezése olyan integrált eszközöként, amelyek mindegyikének megvan a maga célja, de ha együtt használják, meghaladja az alkatrészek összegét, ami nagyjából a UNIX filozófiájának középpontjában áll. Tehát a projektünk kezelési módja (azaz az operációs rendszer kernjének nagy része egyetlen git tárhelyen tartása) sokkal közelebb áll a BSD modellhez (ami egy igazi UNIX, szemben a Linuxszal), hogy elvégezzük a dolgokat (ahol a legtöbb a központi operációs rendszert egyetlen CVS / SVN adattárban tárolják), ami Linuxon soha nem volt ilyen.
Végül nagyon kevéssé számít az a kérdés, hogy valami UNIX-e vagy sem. Mivel műszakilag kiváló, aligha jellemző a UNIX-ra. Számunkra a UNIX a fő hatás (valójában a legnagyobb), de vannak más hatásaink is. Ennélfogva egyes területeken a systemd nagyon UNIX, máshol pedig valamivel kevésbé lesz.
Ez nagyon összetett ...
Ebben bizony van némi igazság. A modern számítógépek összetett vadállatok, és a rajtuk futó operációs rendszer is nyilvánvalóan az lesz, tehát összetettnek kell lenniük. Azonban a systemd természetesen nem összetettebb, mint ugyanazon összetevők korábbi megvalósításai. Egyszerűbb és kevesebb a redundancia. Másrészt egy egyszerű systemd-alapú operációs rendszer felépítése sokkal kevesebb csomagot tartalmaz, mint a hagyományos Linux-alkalmazások. Kevesebb csomag megkönnyíti a rendszer felépítését, megszabadul az egymásrautaltságtól és az összes érintett komponens eltérő viselkedésétől.
Ez nem engedi, hogy shell szkripteket használjak
Ez teljesen hamis. Egyszerűen nem használjuk őket a rendszerindítási folyamathoz, mert úgy gondoljuk, hogy nem a legjobb eszközök erre a konkrét célra, de ez nem jelenti azt, hogy a systemd inkompatibilis lenne velük. Könnyedén futtathatsz shell szkripteket systemd szolgáltatásként vagy démonként; bármilyen nyelven írt szkripteket futtathatsz systemd szolgáltatásként, mivel a systemd-t a legcsekélyebb mértékben sem érdekli, hogy mi van a futtatható fájlban. Sőt, széles körben használunk shell szkripteket saját céljainkra: a systemd telepítéséhez, fordításához és teszteléséhez. A szkripteket beillesztheted a korai indítási folyamatba, használhatod őket normál szolgáltatásokhoz, futtathatod őket a végső leállításkor - gyakorlatilag nincsenek korlátok.
Ezen a ponton azt hiszem, néhány főbb hiedelem tisztázódott. Bár nem tartom magam a változás hívének, és fenntartásaim vannak az „ egyetlen démon uralkodik mindenki felett ” ötlettel kapcsolatban, azt hiszem, hogy végül senki sem meri majd azt mondani, hogy egyáltalán nem működik. Ismerek olyan felhasználókat is, akik észrevették, hogy a systemd-vel „a PC gyorsabban fut”, de ez egy másik megbeszélés tárgya lenne. Egyelőre csak arra kérhetlek benneteket, hogy vitassátok meg a nézőpontotokat az init rendszerrel kapcsolatban, amelyet sok disztribúció átvett, bár a legerősebb reakciók jelenleg a Debian közösségen belül tapasztalhatók, amely még egy új forkot is létrehozott emiatt. Akár tetszik, akár nem, személyes kérdés; részemről csak szeretném megtenni a magamét a systemd demisztifikálásában, amely végül a Jessie-ben, a Debian következő stabil verziójában lesz jelen.
Láttam a GUTL-en található cikket (ami viszont a DesdeAbreus- ból származik ).
Systemd áram?
Azok közé tartozom, akik nem olvasnak sok hírt, ha valami ekkora vitát generál, inkább maradok a technikai részleteknél. Az a helyzet…. Néha úgy érzem, hogy bizonyos témák megszűnnek pusztán technikai jellegű megbeszéléseknek vagy vitáknak lenni, és olyanná válnak, mint a showbiznisz pletyka
Először egy felhasználó nyílt kirohanása a systemd-ről, systemd VS intelligence néven , majd Linus Torvalds azt állítja, hogy a systemd nem olyan rossz , mint amilyennek beállítják ( és igaza van ), egy usefull nevű fork ... nincs hozzászólás... és hogy rövidre zárjam a történetet, végül Devuan.
Nem mondom, hogy annyira rossz-e, mint mondják, kevésbé rossz, vagy rosszabb. A rendszer nálam jól működik, de személy szerint én az init-et részesíteném előnyben, mivel tetszik, ahogyan különféle dolgokat szervez (például naplókat). De hé, ha a systemd-t versenylónak fogják hívni, és le kell váltania az init-et ( vajon az lenne az igáslónk, ami mindent csinálna, csak lassan? ), nos... amíg a változás nem túl drasztikus, a felhasználók gond nélkül alkalmazkodhatnak, és a rendszer jobban működik (igen, jobban, talán ez nekem nem lesz elég!), akkor üdvözöljük! 😉