Všem čtenářkám a čtenářům AbcLinuxu krásné Vánoce.
Byla vydána nová verze 7.0 linuxové distribuce Parrot OS (Wikipedie). S kódovým názvem Echo. Jedná se o linuxovou distribuci založenou na Debianu a zaměřenou na penetrační testování, digitální forenzní analýzu, reverzní inženýrství, hacking, anonymitu nebo kryptografii. Přehled novinek v příspěvku na blogu.
Vývojáři postmarketOS vydali verzi 25.12 tohoto před osmi lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell on Mobile, KDE Plasma Mobile, Phosh a Sxmo.
Byla vydána nová verze 0.41.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 6.1 nebo novější a také libplacebo 6.338.2 nebo novější.
Byla vydána nová verze 5.5 (novinky) skriptovacího jazyka Lua (Wikipedie). Po pěti a půl letech od vydání verze 5.4.
Byla vydána nová verze 5.4.0 programu na úpravu digitálních fotografií darktable (Wikipedie). Z novinek lze vypíchnout vylepšenou podporu Waylandu. Nejnovější darktable by měl na Waylandu fungovat stejně dobře jako na X11.
Byla vydána beta verze Linux Mintu 22.3 s kódovým jménem Zena. Podrobnosti v přehledu novinek a poznámkách k vydání. Vypíchnout lze, že nástroj Systémová hlášení (System Reports) získal mnoho nových funkcí a byl přejmenován na Informace o systému (System Information). Linux Mint 22.3 bude podporován do roku 2029.
GNU Project Debugger aneb GDB byl vydán ve verzi 17.1. Podrobný přehled novinek v souboru NEWS.
Josef Průša oznámil zveřejnění kompletních CAD souborů rámů tiskáren Prusa CORE One a CORE One L. Nejsou vydány pod obecnou veřejnou licenci GNU ani Creative Commons ale pod novou licencí OCL neboli Open Community License. Ta nepovoluje prodávat kompletní tiskárny či remixy založené na těchto zdrojích.
Nový CEO Mozilla Corporation Anthony Enzor-DeMeo tento týden prohlásil, že by se Firefox měl vyvinout v moderní AI prohlížeč. Po bouřlivých diskusích na redditu ujistil, že v nastavení Firefoxu bude existovat volba pro zakázání všech AI funkcí.
K tomu zacleneni: neni se cemu divit, ten kod neni uplne koser. Nicmene zaclenovat se bude. Ale ne jako samostatny "swsusp". Misto toho bude soucasny swsusp vylepsen.
Ano, nvidia muze byt problem pro upstream swsusp. Ze zvedavosti, nepomuze zvyseni SPARE_PAGES v kernel/power/power.h na dvojnasobek? nvidia dela velke alokace behem suspendu a ten soucasny objem ji nemusi stacit. Pricemz si dokazu predstavit, ze ikdyz alokace selze, tak oni vrati nechybovy stav. TOI pouziva std. 2M.
K tomu zacleneni: neni se cemu divit, ten kod neni uplne koser.Což to je mi jasný.
Ale ne jako samostatny "swsusp". Misto toho bude soucasny swsusp vylepsen.Nic proti - pokud se tam teda dostanou všechna vylepšení, která potřebuju, aby mi swsusp fungoval.
Ze zvedavosti, nepomuze zvyseni SPARE_PAGES v kernel/power/power.h na dvojnasobek?Zkusim, až se v tom zase budu někdy rejpat.
Ze zvedavosti, nepomuze zvyseni SPARE_PAGES v kernel/power/power.h na dvojnasobek?Zvýšil jsem, pomohlo*. Dám tomu pár dní testování a uvidíme, jestli se něco nepokazí. (sync před uspáním jsem dělal už doteď a budu v tom pokračovat
)
Situace kolem uspání a hibernace je momentálně v Linuxu tragická. Dalo by se to shrnout asi takto:

Fakt nechápu, jaká převratná změna musela ve verzi 2.6.29 přijít, že to všechny věci kolem uspání do RAM a hibernace poslalo do kytek. Nehledě na fakt, že nové ovladače grafiky Intel jsou už několik měsíců rozbité a nedá se s nimi pracovat. Takže ani toho slavného KMS si člověk neužije.
O Linuxu obecně. Do verze 2.6.28 mně na mých počítačích i všem známým, kteří používají Linux, funovala hibernace bez potíží a totéž platilo o uspání do RAM. Od verze 2.6.29 nevím o nikom, komu by tohle fungovalo.
Pokud je tu někdo s vanilla kernelem verze 2.6.29 a vyšší, komu funguje buď uspání nebo hibernace, ať už s TuxOnIce nebo s původní (podle mě nebezpečnou a nefunkční) implementací, moc rád se od něj něčemu přiučím.
Kdysi jsem řešil problém, že po probuzení počítače z hibernace mi nefungoval IRDA port a musel jsem ho ručně zapnout.
Dokonce jsem to hlásil jako bug a vývojáři TuxOnIce to dali do pořádku prakticky okamžitě. Nicméně ve srovnání s dnešní situací se mi nefunkční IRDA zdá jako titěrný a nesmyslný problém.
2.6.31 vanilla original EEE901 funguje do RAM i na disk - na Prestigio 159W to same - vzdy posledni vydany bios
Týká se to (odhadem) deseti lidí. Hardware mají v podstatě různorodý, někdo starší 32-bit, někdo 64-bit, různé značky. Já nikomu nic nedoporučuju, hardwarem se nezabývám a neradím lidem, co si koupit.
Přiznám se, že kdybych pečlivě hlásil každý bug a snažil se zachytit aspoň jednu rozumnou logovou hlášku přes netconsole, možná by se to dalo vyřešit. Už takové věci nedělám, přece jen toho elánu nemám tolik jako dřív.
Ono se to těžko řeší, když ten stroj odporně zatuhne. Pak nezbývá než přebootovat, zkusit vyhodit nějaký modul, znova zkusit uspat... Na to už prostě nemám nervy. A mám dojem, že před cca třemi lety tam byly mnohem menší problémy (například IRDA), které navíc bylo možné nějak vyřešit. Dnes vidím jenom sekanec a nemám tušení, co se tam děje.
Hibernace, která je přímo v mainline kernelu, se nikdy neprobudí.Nemáte pravdu, mně se probouzí úplně bez problémů. Takže určitě neplatí nikdy. Jádra 2.6.24 - 2.6.30, předtím jsem hibernaci nezkoušel.
Nemá smysl to vůbec zkoušet.Vyzkoušel jsem, fungovala mi na první pokus (distribuční jádra Archu a Debianu). Pravda, pak jsem chtěl obraz paměti šifrovat a na to bylo potřeba upravit skripty v initramdisku, ale bez šifrování mi to šlo v pohodě.
Nechápu, proč tam vůbc je.Nevím, ale řekl bych, že proto, aby fungovala hibernace.
Jen ohrožuje data důvěřivých uživatelůTo tedy nevím, jak může neprobuzení se ohrozit data. Filesystém na tom bude stejně, jako kdyby vypadla elektřina.
a nepřináší žádný užitek.Mně se hibernace docela hodí - spouštění všech služeb trvá strašně dlouho, takhle mám za chvilku počítač přesně v tom stavu, v jakém jsem ho uspal.
Fakt nechápu, jaká převratná změna musela ve verzi 2.6.29 přijít, že to všechny věci kolem uspání do RAM a hibernace poslalo do kytek.Žádných problémů jsem si nevšiml. Akorát jsem trochu zápasil v VirtualBoxím modulem.
Já mám vanilla kernel, takže to nemá smysl takhle srovnávat. Distribuční kernel jsem nikdy nezkoušel a ani to nemám v plánu.
Mně původní hibernace ještě nikdy nefungovala. Pravda je, že jsem to zkoušel jen cca desetkrát, ale pokaždé to naprosto spolehlivě selhalo. Počítač se buď neprobudil, nebo se vůbec neuspal a zatuhl. TuxOnIce donedávna fungoval spolehlivě.
Mně už původní hibernace při jednom z pokusů o uspání poškodila filesystém. Konkrétně to byl Reiser4 a byl to jeden z mála případů, kdy jsem ho musel opravovat pomocí fsck. Mám za to, že se jednalo o něco vážnějšího než ekvivalent výpadku napájení.
Užitek přináší pouze spolehlivá a funkční hibernace. TuxOnIce byl až donedávna ideálním řešením. To, co je dnes v kernelu, mi spolehlivé nepřipadá. I s uspáním do RAM byl problém, protože počítač se cca při každém desátém uspání neprobudil. Jakmile to nemá rozumnou spolehlivost, nemá to smysl. Dnes už mi uspání do RAM nefunguje vůbec, takže je to fuk.
Asi nemá smysl to nějak řešit. Třeba mám špatný BIOS. Taky už jsem líný při každém selhání shromažďovat logy a hlásit bug, což jsem dřív dělával.
Ačkoliv FS je (byl?) to určitě pěknýJe.
slyšel jsem na něj docela dost nadávek co se týče poškození FS.Taky už se mi párkrát rozsypal, ale vždycky to bylo hardwarem. (Vadný disk || vadná RAM || vadný kabel) == (fsck.reiser4: Read nodes: 12345678, Nodes left in tree: 1234567)
.
Ja som sa ale napr. od kernelu 2.6.28 az po 2.6.31 s problemom uspania do ram a nasledneho prebudenia nestretol a pouzivam to kazdy bozi den. Mam ale nvidia kartu a driver z oficialnych stranok. Mozno je to tou intel grafikou, mozno niecim inym na tvojom stroji, no u mna to ide. Co sa tyka hibernacie, to nepouzivam, neviem potvrdit.
Do verze 2.6.28.x fungoval znamenitě TuxOnIce. Od té doby (a od zavedení věcí kolem KMS) buď nefunguje vůbecPro 2.6.29 byl patch a TOI fungoval naprosto bez problémů, nedávno jsem rebootoval s 33 dní uptime.
nebo zrovna pro daný kernel nejsou patche.Pro 2.6.30 patch nebyl, ale zato se v mailing listu objevila adresa na gitový strom, ze kterého se nechalo 2.6.30 udělat a TOI fungoval. Pro 2.6.31 patch je, používám na dvou strojích a na obou funguje.
Možná mám špatný BIOS.
Žádné sr**ky jako TuxOnIce mi do systému nesmíVy jste, pane, vůl.
Vy mi také lezete už delší dobu krkem, obzvláště v diskuzích o KDE a politice, arogance z vás z nich přímo čiší.
Ne, neni vul. Jen spravne tusi/vi, ze TOI pouziva strasne moc hacku.
Včera jsem nahodil aktuální Arší intel ovladače, podle wiki zapnul KMS, rebootoval a měl funkční grafiku včetně KMS. Žádné problémy s grafikou jsem zatím nezaregistroval.Nehledě na fakt, že nové ovladače grafiky Intel jsou už několik měsíců rozbité a nedá se s nimi pracovat. Takže ani toho slavného KMS si člověk neužije.
Právě dnes ten bug uzavřeli, prý už to funguje a nedochází k zamrznutí.
Nicméně otázka je, za jakých podmínek. Například já mám dual head konfiguraci 1050x1680 svisle a 1024x768 vodorovně s překrytím 90 pixelů (aby virtuální screen nepřesáhl limit pro 3D akceleraci). S něčím takovým má KMS pořád těžký problém.
Apeluji na vas, abyste to reportovali. Ikdyz se vam nechce. Takhle to nebudete mit funkcni nikdy. (Ano, na muj vkus linux az moc testovani prenasi na lidi. Ale zaroven nevim, jak to zlepsit.)
Nechci rypat, ale nerozumnel jsem vtipu v komentari ve zdrojaku v citacich, tak jsem se koukl na original... =)
v orig. zni takto:
/* Promote an attitude of violence to a BIOS engineer today */
a v cestine je to podle me:
/* Dnes podpor nasilny postoj k vyvojarum biosu */
Suhlasim s ticcky s tym prekladom. Dufam ze takto zle sa neprekladaju cele jaderne noviny. Asi by som sa mal raz konecne pozriet na original....
Chyby su vsade, ja som ale velmi vdacny za preklady, aj ked mozno len 99,9% spravne. Je to to vyborne citanicko, aj ked zvacsa tomu velmi nerozumiem :D ale to je druha strana mince. Takze dakujem autorovi prekladu.
Jak na zkousku uzavrit popisovac 2, abych si mohl vyzkouset to chovani pri uzavrenem popisovaci?
#include <unistd.h> close(STDERR_FILENO);
2>&-.
Tiskni
Sdílej: