Přejmenování síťových rozhraní v Arch Linuxu

„Je to jen v módě, protože začíná o 3 nebo 4 sekundy rychleji.“
Ve skutečnosti to tak není, ve skutečnosti hlavní vývojář systemd výslovně vysvětluje v e-mailu od svého ML, že nikdy nepřemýšleli o systemd jako o systému rychlého spuštění, že je to jen důsledek toho, jak systemd funguje - což je opravdu šťavnaté přemýšlet o tom, čeho lze dosáhnout, pokud se rozhodnou optimalizovat systém tak, aby byl rychlejší ...

„Výhodou systemd proti sysvinit / openrc nebo upstart není to, že je tak velký“
Pokud jde o SysV init, výhodou je OBROVSKÁ ve srovnání s Upstartem ne tolik.
SysVinit je catramina, vozík vedle Porsche.
Ačkoli SysVinit sloužil svému účelu po mnoho let, realitou je, že implicitní omezení softwaru vyrobeného, ​​promyšleného a navrženého před mnoha lety a pro tento okamžik jsou stále znatelnější.
Některé z problémů se SysV kromě pomalé doby bootování jsou podmínky závodu, které se obvykle vyskytují v různých prostředích, jeho struktura pro aktivaci a deaktivaci démonů a jak složité je přidávat nové aplikace a démony do této struktury bez narušení sekvence. Začátek.

systemd to všechno řeší čistým, praktickým, standardizovaným a dobře zdokumentovaným způsobem - když v SysV je to obecně tak, že každá distribuce to implementuje tak, jak má.

O Upstartu Nevím moc nad rámec jeho konfiguračních souborů, které jsou přísně řečeno SKUTEČNÉ, je to čínština, je mučení je upravovat a je velmi snadné dělat chyby, pokud nejste blázni a neuděláte nepořádek.
Na druhou stranu se Upstart zdá být opravdu efektivní, protože nejnovější verze Ubuntu na mém stroji začaly a vypínaly se téměř okamžitě - skvělé.
Když se však Poettering zeptal, zda opravdu potřebují sysmted a pokud neanalyzovali další možnosti, jako je například Upstart, odpověděl, že ano, analyzovali je, že existuje mnoho věcí, které se jim líbí, a že ve skutečnosti to bylo v plánech implementace ale že podle nich strukturální základna Upstart nebyla dobrá a že je velmi možné, že v budoucnu budou mít z toho odvozené problémy.

Pamatujte, že systemd se zrodil jako iniciativa Red Hat ze dvou důležitých důvodů:
1. Vzhledem k zkušenostem _vastisima_, které má společnost ve svých tisících nasazení, dospěli k závěru, že musí ve svém systému provést určité zásadní změny, aby splnily jejich požadavky, změny, které logicky znervózňují více než jednoho veterána - stejně jako všechny hluboké změny.
2. Nikomu není žádným tajemstvím, že Red Hat se snaží být Red Hat a ne GNU + Linux.

Kromě arabesek a dalších rozptýlení je faktem, že systemd je stále častěji přijímána komunitou GNU + Linux, což je nutně dobré z několika důvodů:
1. vývoj je urychlen, takže lze dosáhnout lepšího produktu za kratší dobu
2. Zahrnutím potřeb různých distribucí a spoluprací s hlavními vývojáři těchto distribucí se systemd a interakcí s vývojáři z jiných distribucí diskutujících o opravách a funkcích je nekonečně snazší dosáhnout kvalitního produktu
3. Je agnostický vůči distribuci, ve které je implementován (velmi důležité!) A konsoliduje se jako standard (stejně jako POSIX) něco, co administrátor, který musí pracovat v heterogenních prostředích složených z různých distribucí, ale kteří sdílejí řídící základnu, bude jistě oceníte podobný systém.
$ systemctl bude na Fedoře fungovat stejně jako openSUSE nebo Arch nebo Chakra nebo Red Hat nebo Kali Linux nebo jakákoli jiná distribuce, která používá systemd a to je skvělé.
4. Mít velké množství vhodných lidí pracujících na stejném PID1, který používá samotné distro, velmi usnadňuje práci samotným vývojářům při řešení problémů nebo při hledání pomoci či nápadů, jak implementovat jednu nebo druhou funkci.
5. Jelikož systemd je otevřený a - velmi důležitý - interdisciplinární projekt, je míra přijetí a zlepšování projektu jedním z nejvyšších z projektů FLOSS.
Například když správce balíčku jakékoli distribuce, který zahrnuje spuštění démonů na začátku, představí svou verzi služby v systémovém seznamu adres a požádá o komentáře a návrhy, stane se, že po obecné spolupráci je možné mít tuto službu bod, tím nejlepším možným způsobem, ten, který používá nejen vývojáře, který téma otevřel, ale také posílá UPSTREAM vývojářům samotné aplikace, aby se mohli rozhodnout, zda chtějí tuto službu vytvořit jako součást svého vlastního balíčku a tím ji učinit 100 % systemd kompatibilní OOTB.
6. systemd má stovky stovek nových funkcí, díky nimž je správa systémů, které spravuje, mnohem jednodušší a plynulejší. Například zodpovídá za správu modulu PAM pro správce přihlašování, správu vzdálených připojení k systému, načítání služeb na vyžádání naslouchajících na soketech místo toho, aby měl démon spící v paměti a krást CPU a paměť čekající na aktivaci, spravovat v spolehlivý způsob síťová rozhraní a zařízení zapojená do systému ... je to opravdu monstrum, obrovský Leviathan, ale na rozdíl od jiných systémů této velikosti funguje hbitě, rychle a velmi hladce a myslím, že jediný důvod, proč tomu tak je , pro OBROVSKÝ systém, jako je systemd (myslíte si, že v krátké době zvládne celý systém), je navržen tak, aby byl efektivní, modulární a škálovatelný od samého začátku.

Z používání systému systemd nejvíce trpím zejména tím, že se musím znovu naučit vše, co jsem dosud používal ke správě svého stroje.
Je pochopitelné, že někteří pravěci, kteří mnoho let používali určitou metodiku, takové změně odolávají ... ale hej! Jedná se o informatiku, zde se nemění jen to, že změna je kontinuální 😉

Zdravím.