Názory k článku FFmpeg 5.0 je venku, Ubuntu 22.04 LTS zůstane u jádra Linux 5.15

Co takhle změnit titulek na "psalo se na phoronixu"? :)

To by nebylo úplně přesné. Ano, Phoronix píše takřka o všem. Já jej využívám jako přehledový zdroj, který nepokrývá vše, případně někdy to napíše později. Myslím že bystrý čtenář si všiml, že často v textech dodávám něco jako "Phoronix k tomu uvádí...", což odpovídá míře využití jeho textu a toho, nakolik původní zdroj obohacuje (fakt nenosím v hlavě vše, takže takto obvykle Phoronixu "dávám kredit"). Ale pak jsou témata, kde Phoronix pro mě není zdrojem, ač o tématu také píše. V případě tohoto konkrétního článku je to vlastně většina témat. A pak jsou témata, která Phoronix nepokrývá vůbec.

I kdyby to bylo "co se psalo na Phoronixu", tak me to neurazi. Spousta lidi si rada precte IT zpravy v cestine. Plus navic Phoronix tomu prirozene muze venovat vic energie (protoze ma potencialne vetsi ctenarskou zakladnu), takze i z toho hlediska mi to prijde prinosne (netvrdim ale, ze vzdycky jsou originalni zpravicky z Phoronixu idealni).

Tak mě spíš šlo o to, jestli to není tak, že se autor podívá na phoronix, cherrypickne co se mu líbí, pak napíše zprávičku a místo "zdroj phoronix" k tomu napíše "phoronix dále uvádí..." - můžeme mít názor na phoronix jaký chceme, ale jeho autor do toho dává hodně energie najít ty věci a tak...

Nevím jak to je, nechci soudit... ale když se podívám na phoronix a pak na root, tak mi přijde, že na rootu nic originálního ve zprávičkách skoro není a přitom těch lidí co tu píšou zprávičky je mnohem víc (phoronix je v podstatě jeden člověk).

Jaky je duvod FFmpeg 5.0, namisto 4.5, kdyz se zadna podstatna revoluce nekona ?

Zde je kratka diskuze, ve ktere se rozhodovalo o 4.5/5.0 http://ffmpeg.org/pipermail/ffmpeg-devel/2021-October/286701.html

ad "uživatelé velmi nového hardwaru budou nejspíš sahat po repozitářích typu Ubuntu Mainline Kernel PPA."

no ono nejde jen o uzivatele "velmi noveho HW", ale i o uzivatele co chteji Hibernovat se zapnutym SecureBoot, protoze pred casem (lety?) nekdo fakt hloupe rozhodl, ze hibernovat se SecureBoot neni bezpecne a v systemovych/re­positarovych jadrech je to umele zablokovane...
pritom rozdil mezi startem cistym a z hibernace neni z pohledu bezpecnosti ZADNEJ rozdil, nacte se bezpecne jadro a initramfs a jeho scripty bud prepnou na rootfs, nebo ho obnovej ze swap, v pripade nepouziti sifrovani budiz, obsah swapu je mozne citelnej, ale ta blokovana hibernace je i kdyz je pouzit LUKS na rootfs a s nim uz je to opravdu hovadina...
takze abych mohl hibernovat, mam UbuntuMainline jadro, i presto ze nepouzivam btrfs, bezi to na 10let starem NB, atd...

a pak je tu druha vec, "pripravatorum" "Ubuntu Mainline Kernel PPA" asi spadne neco na hlavu... dlouhodobe platilo "nepsane(?)" pravidlo ze ty jadra behali ve vsech dostupnych vydani *buntu, pred par mesici ale navysili zavyslot na libc6, takze preslo chodit v *buntu 18.04, pak opet zvedli pozadovanou verzi libc6 ze prestalo chodit bv *buntu 20.04 (tedy poslednim LTS vydani), nedavno aby toho nebylo malo, zmenili zavyslost (od 5.15.7) z libssl1 na libssl3 coz je balicek kterej je dostupnej POUZE v NEvydanym *buntu 22.04, takze dnes oficialne ZADNE vydane *buntu NEumoznuje instalaci UbuntuMainline­Kernel....

protoze jak sem psal potrebuju ho k hibernaci se SecureBoot pripravil sem si nejdriv pro svoje potreby, pak to hodil na github jednoduchej nastroj na instalaci jadra z UbuntuMainline­Kernel kde zminene veci resim "workaroundama" (i kdyz nektere pravda spinave, no zatim funkcni :)
a aktualne mam 5.16.0 v Xubuntu 20.04...

https://github.com/k3dar/kumk

"pripravatorum" "Ubuntu Mainline Kernel PPA" asi spadne neco na hlavu...

podla situacie Mainline uz davno spadlo, co k tomu dodat... asi len toto:
Banda tupych hlav (linka obsahuje hudobne video k teme)

jasne to byl preklep, samozrejme sem myslel "asi spadlo neco na hlavu" :)

> nekdo fakt hloupe rozhodl, ze hibernovat se SecureBoot neni bezpecne a v systemovych/re­positarovych jadrech je to umele zablokovane...
pritom rozdil mezi startem cistym a z hibernace neni z pohledu bezpecnosti ZADNEJ rozdil,

Znie to tak jednoducho a pritom je to zle...

The obvious question is "what does hibernation have to do with keeping root out of kernel space", and the answer is a little convoluted and is tied into how Linux implements hibernation. Basically, Linux saves system state into the swap partition and modifies the header to indicate that there's a hibernation image there instead of swap. On the next boot, the kernel sees the header indicating that it's a hibernation image, copies the contents of the swap partition back into RAM, and then jumps back into the old kernel code. What ensures that the hibernation image was actually written out by the kernel? Absolutely nothing, which means a motivated attacker with root access could turn off swap, write a hibernation image to the swap partition themselves, and then reboot. The kernel would happily resume into the attacker's image, giving the attacker control over what gets copied back into kernel space.

(Zdroj: https://mjg59.dreamwidth.org/55845.html)

> attacker with root access

tak utocnik s root pristupem je asi irelevantni ze muze podvrhnout hibernacni image do swapu, kdyz muze snadneji pozmenit systemove soubory primo v rootfs, nahrat keyloger, rootkit... ;-)

nicmene chapes, ze tebou popisovanej "problem" je totozne i kdyz HW nema (zaplej ci dostupnej) SecureBoot, pritom bez nej stock jadro v *buntu normalne hibernuje?

> tak utocnik s root pristupem je asi irelevantni ze muze podvrhnout hibernacni image do swapu, kdyz muze snadneji pozmenit systemove soubory primo v rootfs, nahrat keyloger, rootkit... ;-)

To nie je celkom tak pravda. Su veci, ktore nevie urobit ani root z userspace, a musi o ne poziadat jadro, aby ich urobil z kernel space. No a ked jadro na to nema kod, treba ho nahrat. Pri zapnutom Secure Boot musia byt aj moduly podpisane a podpis sa kontroluje pri natiahnuti. Pokial si vsak root nieco matla do swapoveho image, ktory sa neskor natiahne bez akejkolvek kontroly, tak sa takato kontrola obide.

> nicmene chapes, ze tebou popisovanej "problem" je totozne i kdyz HW nema (zaplej ci dostupnej) SecureBoot, pritom bez nej stock jadro v *buntu normalne hibernuje?

Ano. Ale chapes, ze Secure Boot zapinas presne na to, aby taketo obchadzanie nebolo mozne? Ked to nechces, Secure Boot si vypni.

@bez přezdívky

nenapada me situace kdy moznost utocnika co ma root, zdiskreditoat hibernate image ve swap by byla horsi nez ze ten utocnik rovnou si vytahne data, prida zadni remote vratka, nahodi keyloger, atd... tedy nic k cemu bu potreboval pridat kernel modul bez podpisu...

proc?? bych si mel vypnout SecureBoot? sem na zacatku jasne (asi jak pro koho ;-) psal ze pouzivam SecureBoot a zaroven hibernaci a proto nemam moznost pouzit distro-stock jadro, ale musim pouzit UbuntuKernelMa­inline (nebo si muzu zbuildit vlastni) kde toto umele omezeni znemozneni hibernace se zaplym SecureBoot neni...

Už víckrát mě napadlo zkusit enkódovat krátké video z foťáku do AV1. Ale ještě nikdy se mi nepodařilo mít trpělivost nechat to doběhnout. Běží to nepředstavitelně pomalu, po dvou hodinách plného vytížení CPU mého zánovního noťasu je to někde u půl druhé vteřiny záznamu na frame 45. Používám FFMpeg 4.4 a libaom-av1. Co dělám špatně? Díky!

Zkuste SVT-AV1, s tím je to sice o něco pomalejší než třeba x265, ale ne nějak propastně.