Na Manjaru jsem to pozoroval naposledy před více jak rokem. Pak se to při nějaké aktualizaci vyřešilo k dokonalosti a nyní když spouštím videa z webu nebo z disku tak se mi spořič nikdy nezapne. Naopak jsem nedávno zkoušel Fedoru-Gnome a tam jsem s tím měl neuvěřitelný problém - během automatického přehrávání na Youtube se sice během jednoho videa spořič nezapl, ale jakmile dané video skončilo, tak se spořič hned zapl a tak jsem na začátku každého videa musel hýbat myší :-)
Vzdycky me pri uspavani do swapu zajimalo, co se stane, kdyz uz pred uspanim jsou ve swapu data, ktera neni mozne zahodit... pak se spanek proste nedovoli?
To bohužel ten problém vůbec neřeší, nebo jen částečně. Ať už mám swap jakkoli velký, může se stát, že v něm není místo pro uložení současné paměti.
Řešením by bylo před uspáním vždy vytvořit další swap o velikosti RAM, a po probuzení ho zase zrušit (a mít samozřejmě dost místa na disku). Ovšem nikdy jsem neviděl, že by to tak někde fungovalo…
Ve Windows to funguje tak, že je pro hibernaci na disku separátní soubor. Hibernační soubor se komprimuje s použitím všech jader CPU, jinak by uspávání a probouzení na strojích s větší RAM bylo dost pomalé.
Mimochodem komprimuje se i swap, nejprve do RAM, a když to nestačí, tak na disk. Komprese prostě výhodná, protože naprostá většina aplikací visí na RAM (a následně I/O), nikoliv na CPU, které se většinou flákají.
Pokud někdo popíše jak to funguje na Linuxu, tak se rád přiučím.
Jak jsem byval spokojen s verzi 14.04, tak jsem ted instaloval 16.04 a moc zmen se neudalo. Je fakt, ze se uz konecne PC znovu pripoji k wi-fi, pokud je od neho odpojena, ale zase treba zamrza system pri delsim pusteni videa. Kdyz je jedna moucha odehnana, prileti dalsi :-D.
To bude asi nějaký omyl. Současná verze Xfce je 4.12 a připravuje se 4.14. Tohle spíš vypadá na verze Xubuntu, ale tahle zprávička se netýká žádné distribuce, ale desktopového prostředí Xfce.
Ne. Celá zpráva je lehce zavádějící, Xfce pouze využívá služeb systému.
V případě systemd je přes DBus odeslána zpráva a ... je to jedno, systemd je zlo, áno? Chytré to je pouze tak, jak je chytrý systemd nebo ConsoleKit a rudimentární drátařina kolem něj.
Pro systemd možno začít zde: https://www.freedesktop.org/software/systemd/man/systemd-suspend.service.html
(je to o cosi složitější, zpráva jde přes logind)
Je to tak.
Uspávání přes systemd je veselé. Hraji si s tenkými klienty jako audio appliance s voyage linuxem = debian jessie. Pro uspávání (tlačítkem power) jsem vždy používal pm-utils, které lze krásně konfigurovat skripty v /etc/pm/sleep.d. To stále lze, ovšem nesmím se přihlásit (lokálně či ssh). V tom okamžiku přebere uspávání logind s úplně jiným způsobem konfigurace a ani po odhlášení se jej nepustí. Ovšem do přihlášení to neřeší, tudíž na standardní provoz stejně pm-utils potřebuji. Fajn vývoj, když se musím odhlašovat rebootem, abych otestoval celý řetězec :-) Třeba by někdo věděl, jak logind přesvědčit, aby do uspávání nefušovalo a nechalo událost zpracovat pm-utils.
pm-utils je hromádka skriptů, které po provedení trochy magie zapíší do /sys/power/state - na základě toho jádro systém požadovaným způsobem uspí. Systemd dělá totéž, magie může být uložena v /usr/lib/systemd/system-sleep/ a celá akce se spustí v reakci na DBus zprávu zaslanou logind. Že se to dělá "jinak" je záměr, protože se předpokládá, že tuto akci spouští uživatel, ten má pravděpodobně spuštěné nějaké aplikace, ty můžou držet Inhibitor Locks a je tedy možné uspání pozdržet a dát aplikacím možnost nějak reagovat.
Odhlašovat se rebootem není třeba, zatímco vědět, jak to celé funguje, třeba je :-)
Popis výše čtu tak, že zatímco před přihlášením stisk tlačítka power spustí nějaký skript balíku pm-utils, po přihlášení stejný stisk tlačítka zavolá přes DBus (třeba) Suspend(). Tomu by se dalo jistě pomoct...