taky me to zarazilo, rozdil v podstate muze delat maximalne o jednu verzi pri vydani, navic co sem cetl tak pokud zvolene RC jadro pri ubuntu kernel freeze nebude ve stable verzi v dobe vydani finalniho ubuntu, tak to ISO vydaji s predchozi verzi jadra a aktualizaci treba za tyden/mesic pak poslou to puvodne vybrane rc jadro az jako stable vyjde...
sice se toto "mozna+1" promitne i do LTS v ramci HWE povysovani pri > XY.04.2+ , ale porad je to jen +1 a mozna, pokud by RC vyslo 1den po ubuntu kernel freeze , tak se zustane u predchoziho stable jako do ted...
co bych naopak uvidal a melo by MNOHEM vetsi vyznam:
1. aby distribucni jadro NEmelo umele zakazenou hibernaci pri aktivnim SecureBoot, nebo alespon NE kdyz by swap byl nad LUKS (coz je prave ta situace ktera nedela zadnej bezpecnostni problem na kterej se pred lety vymlouvaly kdyz tu hibernaci zakazali)
2. aby misto toho ze "Ubuntu Mainline Kernel" (kterej krome vydani aktualnich verzi jadra, NEma zkriplenej tu hibernaci s SecureBoot) zkrouhli pred par lety jen pro posledni vydani *buntu, s oduvodnenim ze to neni pro pouziti s LTS (a pretim bylo) ale pouze pro potreby testovani s posledni i kdyz NonLTS verzi...
tedy aby to zas nejen ze drzelo kompatibilitu s minimalne poslednim LTS s jiz vydanym prvnim opravnym .1 ale aby zaroven pridali vlastni GUI pro instalaci jadra ci prepinac mezi vychozi(GE)/HWE/Mainline kterej by pak umoznil aktualizovat na Mainline verze v ramci beznych aktualizaci podobne jako se deje s "prepnutim" na HWE...
Stejný problém má i 22.04. V repu Ubuntu je totiž Virtualbox 6.1, který je už bez podpory, je třeba přejít na Virtualbox 7, který v repu Ubuntu (ještě?) není.
Z rychlejší adopce novějších jader tedy nadšený nejsem, bude větší tlak na to, aby všechny balíky z oficiálních repozitářů byly s jádrem kompatibilní a to už teď drhne. Staré zlaté pravidlo, že když správce nezaplevelí systém repozitáři třetích stran, má updaty bez problémů, nějak přestává platit.
A povezte nam Kefaline, co si predstavujete pod takovym "otestovanym" jadrem. Ani v Canonicalu nemaji veskery hardware, na kterem to muzete pustit. To same plati i o vyvoji v samotnem upstreamu. A kdyz se podivate i na "LTS" kernely z upstreamu, tak se nebavime jen o bugfixech, ale tam se obcas preportuji i zcela nove veci (a tim nemyslim prkotiny typu pridani devid). A vesmes vic problemu pusobi prave podobne backporty, kdy se pretahne nejaky kus kodu z novejsiho jadra... ale nejaka zavislost jinde utece. A poznate to az ve chvili, kdy to pustite na explicitne dotcenem hardware.
@LolPhirae
Vytrhl si to z kontextu, jde o datum "kernel freeze", viz
Na palici je spis tva uvaha bez precteni/znalosti podrobnosti:
- pripadne RC verze se zvoli v den "kernel freeze", nikoliv v den *buntu release, ktery je az o 2 mesice pozdeji
- pokud dane RC neprejde do stable do terminu *buntu release, NEbude vydano s RC, ale s predchozim stable jadrem a to RC dostane o par dnu/tydnu/mesic pozdeji az stable vyjde
Konkretne (verzema smysleny priklad)
- pokud by napr. 15.2.(kernel freeze) bylo stable 6.5 a 6.6-RC, tak drive se zvolilo 6.5, ted se bude volit 6.6
- pokud by 15.4 (release date) bylo 6.6 stable, vyjde ISO s nim, pokud by jeste nebylo vyjde ISO s 6.5 a na 6.6 ktere by stable vyslo 30.4. dostane nasledne aktualizaci beznou cestou balicku