Arch Linux a můj přechod na systemd

17.8.2012 20:42 | Přečteno: 3837× | Linux |

Tak jsem zkusil přejít na ten zlý, hnusný systemd.

Příprava

Co budeme potřebovat:

• jeden aktuální Arch (v případě chuti jich může být více),
• články na Arch Wiki: o systemd, o démonech, o službách systemd,
• pročíst si třeba na [arch-general], co je to za člověka ten Lenart, a jak je Pulse Audio k ničemu, ať víme do čeho jdeme,
• zálohu dat a aktuální konfigurace, ale to má přece každý,
• obětiny příslušným božstvům.

Instalace

Příslušné balíčky pro první kolo jsou: systemd a systemd-arch-units.

Nastavení

Následuje úprava konfigurace zavaděče, třeba takto (GRUB 2 na hikari, ano píšu si ručně grub.cfg):

# (0) Arch Linux GUI Mode
menuentry "Arch Linux GUI" {
search --fs-uuid --no-floppy --set=root 0a65abc8-fd5f-4e5a-9177-f5fedf9137c7
linux /vmlinuz-linux cryptdevice=/dev/disk/by-uuid/7b31337e-021d-421f-91df-0a81277825ed:hikari_ssd_luks root=/dev/hikari_ssd_lvm/root resume=/dev/hikari_ssd_lvm/swap ro quiet pcie_aspm=force 5 i915.i915_enable_rc6=0 init=/bin/systemd systemd.unit=graphical.target quiet
initrd /initramfs-linux.img
}

# (1) Arch Linux CLI Mode
menuentry "Arch Linux CLI" {
search --fs-uuid --no-floppy --set=root 0a65abc8-fd5f-4e5a-9177-f5fedf9137c7
linux /vmlinuz-linux cryptdevice=/dev/disk/by-uuid/7b31337e-021d-421f-91df-0a81277825ed:hikari_ssd_luks root=/dev/hikari_ssd_lvm/root resume=/dev/hikari_ssd_lvm/swap ro quiet pcie_aspm=force i915.i915_enable_rc6=0 init=/bin/systemd systemd.unit=multi-user.target verbose
initrd /initramfs-linux.img
}
		

Parametr init je potřeba jen do případné pozdější instalace systemd-sysvcompat. Parametr systemd.unit=multi-user.target říká, že se má nabootovat do obdoby runlevelu 3, ze kterého provádím upgrady a synchronizaci dat s notebookem. graphical.target je pak obdoba runlevelu 5 a je výchozí, v mém případě proběhne automatické přihlášení do KDE. Parametrem quiet se zbavíme většiny výpisů během startu, s verbose budou vidět.

Většinu dalších potřebných konfiguráků už v systému máme od konce července. Dle Wiki jen zduplikujeme nastavení času a jazyka:

 [nik@hikari ~]$ cat /etc/environment 
#
# This file is parsed by pam_env module
#
# Syntax: simple "KEY=VAL" pairs on separate lines
#
LANG=cs_CZ.UTF8
 [nik@hikari ~]$ cat /etc/timezone
Europe/Prague
		

Pokud chceme používat syslog-ng, nastavíme v /etc/syslog-ng/syslog-ng.conf nový socket unix-dgram("/run/systemd/journal/syslog");.

Spouštěné služby

Nyní určíme, které služby se mají spouštět. Aby to fungovalo, musí existovat příslušné .service jednotky. Ty dodané s balíčky najdeme v /usr/lib/systemd/system/, některé další v posledním odkazovaném WIKI článku. V mém případě šlo o: network (statické nastavení sítě), cpufreq (nastavení škálování frekvence CPU), rc-local (spouštění skriptu /etc/rc.local, používám pro zapnutí numlocku a SPDIF), transmissiond a cron (stačí namísto dcron nainstalovat cronie). Příslušné .service soubory pak patří do /etc/systemd/system/, stejně jako ty, co si sami upravíte. U mě šlo o openntpd.service, kam jsem přidával volbu -s, ježto openntpd nerad velké změny času.

Když máme všechny .service jednotky po kupě, povolíme je třeba takto (dbus a alsa-* povolovat netřeba, naopak preferovaný display manažer ano):

		systemctl enable {všechny,služby,co,chci}.service
		

.service jednotky, neřeší ale jen démony, ale také LVM a další. Pro klasické „viditelné“ LVM je tu lvm.service, pro LVM na šifrovaném svazku odemykaném přes /etc/crypttab (u mě druhý disk) je tu lvm-on-crypt.service.

Závěrečná konfigurace

Pokud jsme všechno nastavili správně, po restartu už najede systemd. Podle naší chybovosti se můžeme setkat s login promptem, chybně spuštěnými jednotkami ve výpisu systemctl či journalctl, záchraným režimem emergency.target, Lenartem se zlým zábleskem v očích, …

Nyní vyčistíme systém od SysV initu: pacman -R initscripts sysvinit a pro korektní nastavování locale a hezké symlinky nainstalujeme systemd-sysvcompat. No a máme Arch Linux bez rc.conf.

Pár čísel

Relevantní část bootu (Zadání LUKS hesla – KDM) trvá cca 7 vteřin, oproti s sysvinitem naměřeným 8 vteřinám je to v nerozlišitelné oblasti. systemd-analyze dává následující čísla, jež ale se sysvinitem porovnat neumím:

Startup finished in 13443ms (kernel) + 8906ms (userspace) = 22350ms

Za ně pak viní především openntpd, což je způsobeno zmiňovanou volbou -s:

  5080ms openntpd.service
  1809ms systemd-cryptsetup@hikari_hdd_luks.service
  1793ms systemd-udev-settle.service
   531ms lvm.service
   296ms network.service
   226ms lvm-on-crypt.service
   218ms systemd-logind.service
   209ms console-kit-log-system-start.service
   174ms rc-local.service
   160ms systemd-user-sessions.service
   156ms systemd-udev-trigger.service
   150ms systemd-vconsole-setup.service
   140ms systemd-modules-load.service
   139ms systemd-sysctl.service
   137ms sys-kernel-debug.mount
   130ms dev-mqueue.mount
   116ms dev-hugepages.mount
    96ms cpufreq.service
    70ms console-kit-daemon.service
    66ms systemd-remount-fs.service
    63ms home-nik-Dokumenty.mount
    53ms var.mount
    53ms home.mount
    33ms boot.mount
    30ms backup.mount
    23ms systemd-tmpfiles-setup.service
    16ms systemd-udevd.service
    13ms upower.service
     9ms tmp.mount

Závěr

Pokud člověk nedá na různé zdejší i cizí kvákaly, a nezalekne se obsáhlého a místy možná trochu nejasného článku na WIKI, není přechod na systemd nic složitého a na třetím stroji to už děláte zpaměti. A teď si jdu sehnat azbestové spodky…

       

Komentáře

[dsdsdsd]

ja dam update.microsoft.com a nemusim skakat po forach a hladat navody a pytat sa hore dole po rieseniach a bat sa ze toto budem zazivat pocas kazdeho upgradu...

[otula]

Vím, že se trollové nemají krmit, ale jedno sousto ti hodím: v rámci update.microsoft.com se určitě neřeší tak zásadní změny. Takže to znamená spíš koupě nové verze systému a nová instalace...

[kavol]

+1

jasně, zní to jako flamebait ... ale má to velkej kus pravdy, kterej zdejším "nekvákalům" s azbestovejma spodkama prostě nevysvětlíš ... prostě každej má hodiny času řešit po fórech, jak to vlastně zupgradovat ...

[mrv]

lulz, ten velkej kus pravdy imo chape kazdy krom tebe, arch (a rolling release distra obecne) nejsou pro kazdeho...

[kavol]

ano, to už jsem pochopil, že z Archu se stalo distro pro masochisty - to ovšem rozhodně nelze zobecnit na jakékoli rolling release distro, třebas v Gentoo si nutnost dělat nějaké manuální kroky nevybavuju ani nepamatuju, možná někdy při přechodu velkých verzí GCC, což je u source distra vcelu pochopitelné a omluvitelné, a to bylo naposled před více než pěti lety tuším (gcc 3 => 4)

[R]

Skleroza? Napriklad prechod na openrc...

[kavol]

Skleroza? Napriklad prechod na openrc...

ehm ... "Migration to OpenRC is fairly straightforward; it will be pulled in as part of your regular upgrade process by your package manager."

(k následně zmíněnému dispatch-conf - etc-update dělám automaticky pokaždý, to nepovažuju za extra migrační krok)

jestli to někomu nezafungovalo, hm, smůla - ovšem jest jistý rozdíl mezi nutností ošetřit speciální případy, a nucením všech do ruční migrace

[Ruža Becelin]

prostě každej má hodiny času řešit po fórech, jak to vlastně zupgradovat ...

Tohle plati do puntiku presne o update.microsoft.com - Kvuli jejich dementnim 0x8xxxxx chybam je clovek na foru kazdou chvili, kde stejne najde ho*no (krome MS MVP "expertu", kteri tam neco kvaknou a hned si oznaci odpoved za spravnou).

Posledni zazitky:

• Aktualizace B se nenainstaluje, protoze je nainstalovana aktualizace A (proc se _software_ instaluje jako KBxxxxxx nechapu doted). Reseni: odinstaluje se aktualizace A, nainstaluje B, nainstaluje A. (rozhodne primocare pro BFU)
• Aktualizace A nainstaluje novy ovladac sitovky (certifikovany MS), ovladac oznami Zarizeni nejde spustit a zrusi pripojeni k siti. Roolback nefunguje, protoze si Windows mysli, ze se jedna o jine zarizeni, PC nema mechaniku, takze saskujeme s extrahovanim setupu na flashku.
• Nove aktualizace obsahuji MS * Essentials, ktere koliduji s resenim treti strany (viz prvni bod), takze pred kazdou atualizaci clovek musi prochazet seznam, co se bude instalovat.

Nerikam, ze instalace v Linuxu je bez problemu, ale u Windows si (hlavne spravci Windows siti) uziji az dost...

[stativ]

U třetího bodu lze ve Win XP i Win 7 snadno zakázat, aby se ten jejich antivir v aktualizacích neobjevoval (totéž platí i pro jiné aktualizace).

[mimi.vx]

což většina BFU stejně nezná ...

[kavol]

prostě každej má hodiny času řešit po fórech, jak to vlastně zupgradovat ...

Tohle plati do puntiku presne o update.microsoft.com - Kvuli jejich dementnim 0x8xxxxx chybam ...

další, co nechápe rozdíl mezi bugem a featurou?

[R]

Ze sa vie windows update rozbit kvoli 1000 roznym dovodom a nikdy to nevypise skutocnu chybu, to je fakt uzasna feature...

[kavol]

ovšem o tomhle to nebylo ... nicméně soustředit se na pointu místo hloupého trollování, přičemž bychom třeba museli přiznat, že linux není dokonalý, to se tady nenosí, že?

[otula]

Za sebe mohu říct, že to, co mne před (celkem dost) lety přitáhlo k Archu, byl asi tak z 90 % právě /etc/rc.conf. Takže musím říct, že se mi cesta, po které Arch nyní kráčí, vůbec nelíbí (a je mi úplně putna, jestli je to pro dobro věci).

[Jinan Dvoulalocny]

Jako další dlouholetý uživatel Archu se musím přidat, +1.

[Limoto]

+1, mezi další věci, co mě vytočily jsou povinný checksumy v PKGBUILDu (už dávno - totální buzerace...) a podepisování balíčků (to má svoje výhody, ale prostě... v jednoduchosti je síla). Co je mi úplně jedno je sjednocení binů a libů... Ale celkově mě přijde, že se mi ten Arch líbí čím dál tím míň

[jyrki]

+1 tohle by se dalo tesat do kamene

[lmb]

+1

V tomhle jsou právě geniální "konzervativní" *BSD systémy. Kdyby mi fungovala hibernace a líp 3D akcelerace u nVidie, tak už jedu 100% na NetBSD/FreeBSD.

[mrv]

http://allanmcrae.com/2012/08/are-we-removing-what-defines-arch-linux/

je mel rc.conf taky rad, ale za posledni 2 roky jsem na nej vubec nesahnul (na rozdil od jinych konfiguraku), takze to (krom trochy nostalgie) nebude vubec zadna ztrata.
a se smerovanim archu to nema imho nic spolecneho, protoze arch byl (a stale je): jednoduchy a rychly pacman + vanilla balicky + rychle updaty
zruseni (temer) nepouzivaneho konfigraku, ktery navic porusoval ten 2. princip, skutecne zmena smerovani neni...

[kralyk z abclinuxu]

Za sebe mohu říct, že to, co mne před (celkem dost) lety přitáhlo k Archu, byl asi tak z 90 % právě /etc/rc.conf.

Proč? To je ten typ konfiguráku, kterej člověk nastavuje jednou za 100 let. Celkem nevidim moc velkej rozdíl mezi skrolováním v jednom dlouhým souboru a editováním několika malých...

A síť se v tom stejně rozumně nastavit nedala...

Jestli mně se něco u Archu libí, tak je to pacman.

[otula]

Proč? To je ten typ konfiguráku, kterej člověk nastavuje jednou za 100 let.

A které konfiguráky se nastavují denně (či měsíčně)?

Celkem nevidim moc velkej rozdíl mezi skrolováním v jednom dlouhým souboru a editováním několika malých...

Po hledání konfiguráků v "klasických" distribucích pro mne byl rc.conf něžným pohlazením. Přehledný, jednoduchý, funkční.

A síť se v tom stejně rozumně nastavit nedala...

Já jsem v něm vždy nastavil síť v pohodě i s více síťovými kartami.

Jestli mně se něco u Archu libí, tak je to pacman.

Když už mluvíš o balíčcích, tak za mne je to spíš ABS. Pacman sám o sobě nějaké výhody oproti jiným nemá.

[kralyk z abclinuxu]

A které konfiguráky se nastavují denně (či měsíčně)?

No, asi takhle: rc.conf jsem nastavil, když jsem instaloval Arch, a od tý doby jsem na něj nešáh (snad kromě přidání kfortune 2 roky zpátky). Zato jiné konfiguráky jsem od tý doby určitě editoval vícekrát. Třeba pacman.conf, httpd apod...

Já jsem v něm vždy nastavil síť v pohodě i s více síťovými kartami.

Na statické konfiguraci to asi jde, ale pro notebook na cesty to není.

[kotyz]

Pro notebook se hodí wicd (i s tim gtk klikátkem) a nenastavuješ nikde nic...

[Fluttershy, yay!]

Když jsem měl na Archu wicd já, musel jsem si ho hodit tuším do démonů nebo kam. Něco jsem nastavit musel.

[kotyz]

Jo, do démonů v rc.conf, ale tim to hasne. Pak už si to jede po svym, zjistí k čemu se dá připojit a zkusí se připojit a kdyžtak se zeptá na heslo nebo tak. A pamatuje si to, takže neotravuje zbytečně znova s tim samym. Podle mě je to lepší než networkmanager, protože to tolik nesaje a nezávisí to na tolika věcech (jako gnome-keyring třeba kterej zase závisí na spoustě jinejch věcí).

[Fluttershy, yay!]

NetworkManager s rozběhnutím GSM modemu na pár kliknutí už mi několikrát zachránil koule.

[kralyk z abclinuxu]

No, však jo, nějakou tuhle utilitu to chce, wicd nebo nm nebo něco takovýho...

[otula]

Zato jiné konfiguráky jsem od tý doby určitě editoval vícekrát. Třeba pacman.conf, httpd apod...

pacman.conf moc editací nepotřebuje (nebo snad měníš co chvíli použité repozitáře?) a httpd? Snad občas virtualhosts?

Na statické konfiguraci to asi jde, ale pro notebook na cesty to není.

No na notebooku používám networkmanager

[kralyk z abclinuxu]

pacman.conf moc editací nepotřebuje (nebo snad měníš co chvíli použité repozitáře?) a httpd? Snad občas virtualhosts?

IgnorePkgs měním dost často. U httpd jsem párkrát měnil interface a ještě něco, už nevim co, nějaký experimenty...

No na notebooku používám networkmanager

+1

[otula]

IgnorePkgs měním dost často.

Ignorované balíčky měním jen výjimečně. Od počátku tam mám linux-lts a linux-lts-headers (používám vlastní konfiguraci jádra), a jediné, co jsem doplňoval, byl cinepaint (poslední verze je nějaká rozbitá, neumí otevřít nic, než .xcf). jinak mi funguje vše bez problémů (ale to je samozřejmě otázka balíčků v systému).

U httpd jsem párkrát měnil interface a ještě něco, už nevim co, nějaký experimenty...

Tak experimentovat se dá s čímkoliv. Až tě experimentování přestane bavit, už na ten kofigurák moc sahat nebudeš :)

[kralyk z abclinuxu]

Tak experimentovat se dá s čímkoliv. Až tě experimentování přestane bavit, už na ten kofigurák moc sahat nebudeš :)

Anebo jo

[otula]

[Václav "Darm" Novák]

Ale no tak… rc.conf se rozsekal do několika souborů s defakto stejným formátem a jenom démony řeší systemd, což není nic hrozného.

[otula]

Magnetem Archu byla pro mnoho lidí jeho jednoduchost a přehlednost - ve všech směrech dotažená snad k dokonalosti. Když jsem ho kdysi poprvé instaloval a konfiguroval, zvládnul jsem to kompletně bez jediného nahlédnutí do wiki. Po mnoha letech jeho používání a zkušeností s ním jsem to před pár týdny, kdy jsem Arch potřeboval opět instalovat, bez wiki nezvládnul ani omylem. A není to tím, že bych zdegeneroval.

[kotyz]

Dřív taky byla pomalu celá wiki jako komentáře v konfigurácích - za starejch dobrejch časů bylo rc.conf "samo-vysvětlující", bylo tam co která volba dělá a jaký parametry se dají použít a co dělají. Po nějaký době ty komenty s novou verzí balíku filesystem z rc.conf zmizely a pak zmizela i většina voleb a přesunuly se do jinech konfiguráků a s definitivnim přechodem na systemd zmizí rc.conf docela. Je to škoda. Taky sem po dlouhý době nově instaloval arch na acera a bez wiki by to nešlo a to bych řek že se v něm docela vyznam. Aspoň máš jistotu že si na nic nezapoměl, než když se tahaj z paměti všechny instalační a poinstalační úkony.

[mess]

Taky se ty komentáře přesouvaly třeba do manuálových stránek - viz man archlinux.

[kotyz]

No ty já moc nečtu, třeba takovej man mplayer, to je tak na tejden...

[kralyk z abclinuxu]

Dáš man mplayer (nebo něco), pak dáš lomítko, napíšeš co tě zajímá (regexp) a odentruješ Případně klávesou n a p se posunuje ve výsledcích. Tak to alespoň řešim já...

[Mrkva]

Uz jsem o systemd nechtel trolovat, ale tohle mi neda:

init=/bin/systemd

Init v /bin? Coze? To je vymysl Archu nebo systemd?

[kotyz]

Do roka a do dne stejně bude /bin i /sbin jenom symlink do /usr

[Mrkva]

Copak o to, o tom už jsem flamoval a když někdo chce slít /{,s}bin do /usr/{,s}bin tak dejme tomu. Ale motat dohromady /sbin a /bin? Není to už trochu moc?

[mrv]

ono je to jedno, kdyz v archu bude co nevidet stejne jen /usr/bin

[stativ]

Podle PKGBUILDu je to výmysl systemd.

[rADOn]

IMO je to aby mohl user posilat daemonovi signaly a je to tak spravne.

[Michal Vyskočil]

Komunikace systemctl probíhá přes /run/systemd/private. Důvodem, proč je to v /bin je, že systemd by měl do budoucna nahradit i sedící správce desktopových prostředí. Proto dokáže běžet i jako ne PID 1 program. Aktuálně se mluvilo o něčem pro Gnome 3 a někdo z Intelu pracuje na něčem podobném pro Tizen.

[belisarivs]

No, problem s prechodem zjevne nebyl. Usetril jsi tim celou jednu vterinu casu (a nastavovanim jich promrdal tisice). Nicmene, nejak mi chybi odpoved na jednu otazku. "Proc?"

[mess]

Protože se z toho stane vývojáři distribuce preferovaná varianta a do budoucna to z toho důvodu slibuje minimum komplikací. Tak možná proto

[jyrki]

A to je to co mi vadi, misto ignorace a protestu dobrovolne prejde a bude jim delat testera. Arch upada, doufal jsem ze neco jako systemd nikdy do Archu neprijde. Asi mi nezbude jine cesty nez jit zpet k FreeBSD. A nebo nekdo Arch forkne a bude zase o jedno zbytecne distro navic (a tim myslim puvodni Arch, ktery se zproneveruje svym uzivatelum)...

[mess]

Tak určitě. Když to někdo forkne ... tak to bude forknutý, no ... a to je blbý, jelikož se tříští síly a tak. Ale jak říkám ... je to sport

[Radek Hladik]

No, to svědčí o jediném, a sice o tom, že vývojáři Archu dokázali převést boot systému pod systemd, v principu to nevypovídá nic o (ne)kvalitách systemd. Tedy krom toho, že alespoň zdánlivě zvládne to samé, co staré řešení... Já teď připravuju instalaci Fedory 17, kde mám různé netriviální požadavky (boot z iSCSI, nestartovat raidy při bootu, nějaké starší init skripty...) a musím říct, že zatím je to nastejno... Například potřebuju, aby se při bootu automaticky nenahodily všechny raidy, tak jsem si říkal, super, to bude pěkné, najdu ten unit file, který se stará o raidy, a řeknu mu "disable". No nakonec jsem našel, že je to unit file ke skriptu /lib/systemd/fedora-storage-init, který inicializuje i LVM a dmraid...

Další legrace je, že dřív init skripty mohly mít různé "příkazy", třeba "service postgresql initdb". Asi to není moc čisté, ale bylo to funkční. Systemctl ovšem nic takového neumožňuje (koneckonců nejdřív se zadává příkaz až pak služba). U postgresu tedy mají samostatný skriptík, který ale ze systemd pomocí nějakého get-environment tahá nastavení (například, kdeže vlastně ta DB má na disku být). Docela jsem se nasmál, když jsem v komentáři našel, že díky tomu, že systemd vypisuje proměnné na jeden řádek, není možné mít v cestě mezeru...

A na závěr ještě jedno popíchnutí. Kdyby pan LP místo přemýšlení, kde co ještě víc rozvrtat a překopat od základů, myslel trochu víc na použitelnost, možná by ho napadlo služby označovat service.neco místo neco.service, aby se to lépe tabkovalo.

[kavol]

Další legrace je, že dřív init skripty mohly mít různé "příkazy", třeba "service postgresql initdb". Asi to není moc čisté, ale bylo to funkční. Systemctl ovšem nic takového neumožňuje (koneckonců nejdřív se zadává příkaz až pak služba). U postgresu tedy mají samostatný skriptík, který ale ze systemd pomocí nějakého get-environment tahá nastavení (například, kdeže vlastně ta DB má na disku být).

po velkých bojích (...) systemd team klesnul na kompromis, že u příkazu "service" bude zachována zpětná kompatibilita, a tedy zatímco "service postgresql initdb" dříve volalo "/etc/init.d/postgresql initdb", nyní už konečně místo vyblití chyby zavolá moderní ekvivalent v podobě "postgresql-setup"

až se Lennart ještě kousek vzdálí, tak se nám možná vrátí i podpora oněch speciálních akcí namísto pevně daného seznamu, o kterém si myslí, že prostě musí stačit každému a všude ...

[Radek Hladik]

To zní lákavě. Já ale vidím problém v tom, že se u systemctl nejdříve píše akce a pak služba, takže to nebude tak pěkně elegatní jako u service, kde si vytabkuju službu a pak se tabkou podívám, co všechno umí...

[pavlix]

možná by ho napadlo služby označovat service.neco místo neco.service, aby se to lépe tabkovalo.

Spíše hůře, ne?

[mess]

Zkuste "tabkování" v zsh a přestaňte se hádat

[pavlix]

V čem se liší? Doplňuje xyz.service nějak jinak než třeba bash?

[mess]

Doplňuje jinak. Třeba se dá nastavit, že doplňuje i podle částí slov, takže po napsání systemctl start xyz<TAB> doplní správně ať už se má doplnit xyz.service nebo service.xyz.

[pavlix]

Zajímavé. Pak mu ale může být to pořadí jedno, zatímco v bashi vychází líp ta varianta, která se v systemd používá.

[nyan]

Dotaz pro autora blogpostu: co *konkretne* jste *vy* ziskali ? Nechci slysel o tom co systemd *umi*, to si umim vygooglit. Ptam se jaky realni prinos(y) to ma pro vas, co jste za ten cas co to mate zjistili.

Zatim jsem z vaseho blogpostu zjistil, ze si clovek musi precist a naucit se, jak se spousta veci dela "nove a lip" - jakoze treba runlevely jsou uz asi obsolete ? Tudiz se ptam co za to realne dostanu.

Dekuji

[mess]

Nevím, jak autor blogpostu, ale za mě to je rychlejší boot o cca 10 sekund.

[kotyz]

To je teda velký terno, zvlášť pro někoho kdo bootuje jen jednou denně nebo ještě míň často...

[mess]

Že v tom nevidíš žádný smysl, neznamená, že v tom ten smysl nevidí někdo jiný

[kotyz]

Notorický restartovači určitě

[mess]

trololo

[kralyk z abclinuxu]

Notorický restartovači určitě

Hele, jó, ne každej má v ntb 10Ah baterii...

[kotyz]

Né každej má v notebooku funkční baterii...

Já to mam jako přenosnej desktop kterej neni kam ani proč přenášet

[Nicky726]

Potvrdil jsem si, že to co je z části komunity o systemd slyšet je značně nadsazená démonizace. Je to prostě další init systém, který funguje (to, co od něj potřebuju, udělá – pravda, mé nejzáludnější požadavky jsou LUKS nad LVM a LVM nad LUKS).

Z některých komentářů zde i jinde nabývám dojmu, že učit se něco nového, je strašně špatně. Já to tak nevidím. Když už nic jiného, tak pokud někdo bude požadovat znalost systemd mám praktickým využitím podpořenou znalost. A pak, člověk se učením nových věcí rozvíjí a zabraňuje zakrnění.

Přechod, původně zkoušku, systemd jsem dělal zejména proto, že Arch k jeho využití směřuje a nyní v létě se mi to hodí více než během semestru. Pořád ještě spravuju SELinux pro Arch, takže si potřebuju systemd osahat, abych to mohl v budoucnu rozchodit se systemd.

Hodně se propagovalo zrychlení bootu, na hikari jsem to už před rokem vyřešil SSDčkem, takže tam se to viditelně neprojevilo. Čísla z kanashimi, kde je harddisk a jednojádro, nemám.

Ad runlevely, existují .targety. Jméno jiné, funkčnost stejná, idea podobná. Osobně jsem využíval přepínání mezi 3 a 5, takže nyní přepínám mezi multi-user.target a graphical.target. Vzhledem k symlinkům z systemd-sysvcompat to lze používat i postaru.

systemctl -H zjednoduší některé operace.

[kavol]

Z některých komentářů zde i jinde nabývám dojmu, že učit se něco nového, je strašně špatně.

to v žádném případě

nicméně nač se učit něco nového, když už to staré umím a funguje?

si představ ... u nás se jezdí vpravo, v Británii vlevo, co kdybychom si to prohodili, aby se každý naučil něco nového? budeš takovou změnu obhajovat s těmito argumenty?

A pak, člověk se učením nových věcí rozvíjí a zabraňuje zakrnění.

správná myšlenka, ale neskutečně špatně aplikovaná

viz výše - namísto toho, abych se přeučoval něco, co již umím, a starou znalost zahazoval, je mnohem efektivnější abych staré nezahazoval, a čas ušetřený tím, že se nebudu přeučovat, věnoval raděj učení se něčeho opravdu nového, co mě posune dál ... nebo ty snad vidíš smysl života v tom strávit ho tím, že se pořád dokola budu učit to samé ale pokaždé v novém systému?

[Ruža Becelin]

si představ ... u nás se jezdí vpravo, v Británii vlevo, co kdybychom si to prohodili, aby se každý naučil něco nového? budeš takovou změnu obhajovat s těmito argumenty?

Ono se puvodne v Evrope jezdilo vlevo, takze tenhle priklad pada, protoze lidi se museli preucit na jizdu vpravo a "zahodit" znalosti, co nabyli pri rizeni vlevo...

[kavol]

Ono se puvodne v Evrope jezdilo vlevo,

vážně? i v takové Francii, v Německu, v Norsku ...?

takže tvoje námitka padá, protože ani neznáš historii :-p

takze tenhle priklad pada, protoze lidi se museli preucit na jizdu vpravo a "zahodit" znalosti, co nabyli pri rizeni vlevo...

právě naopak, tento příklad je výše uvedenou historickou zkušeností krásně podložen; stejně tak jako jej mohou potvrdit současníci, kteří cestují mezi různostrannými zeměmi

[Petr Ježek]

tak jsem se odhodlal naistalovat systemd-sysvcompat, což mi v důsledku konfliktu zabackovalo rc.conf a inittab. Postupoval jsem striktně podle wiki a maje systemd-sysvcompat, zrušil jsem init parametr v kernel řádku v /etc/default/grub. Budiž, řekl jsem si, leč tu máš čerte kropáč - po rebootu se spustí emergency mode a zacykluje se v neustálém zabíjení nekomunikujícího systemd-něco přes worker. Samozřejmě to jde opravit přes rescue disk, co je ale špatně, že si po dvouměsíční bezpoblémové práci s koexistujícím systemd s rc.conf a inittabem musím zanadávat na systemd bez jistoty, kde je vlastně chyba?

[Eduard Štembírek]

Přechod není žádná katastrofa. Navíc archáč startuje pekelně rychle a vůbec vše šlape jako po másle. Autor jen zapomel na konfiguraky,bez nich to asi nabehne taky, ale je lepsi mit vse tip top. : - )