Fórum Root.cz
Hlavní témata => Software => Téma založeno: Jerry999 26. 12. 2025, 18:11:28
-
Mám starší notebook (Aspire one D270), který roky dobře fungoval s Ubuntu Mate 20.04, ale nemohl jsem upgradovat výš kvůli potížím s ovladačem integrované grafické karty.
Ano, GMA3600 se Intelu moc nepovedla, kdysi tam fungovala i hw akcelerace videa a 3D, což v Linuxu záhy úplně zrušili, nicméně na brouzdání po internetu ve vlaku mi ten notebook stále vyhovuje.
Tak jsem využil vánočního volna, nainstaloval Linux Mint 22.2 Xfce, začal jsem stahovat různé verze kernelu, snažil se přijít na to, co se v driveru gma500_gfx rozbilo a jak to opravit. Poslední plně funkční byl Linux kernel v6.0. První chybu do driveru vložili ve v6.1 a druhý problém se objevil ve v6.5. Oba problémy jsou dodnes nevyřešené (zkoušel jsem 6.18.1) a defakto znemožňují používat s touhle grafickou kartou jakoukoliv současnou Linuxovou distribuci (v 50% končí boot černou obrazovkou).
Obě chyby se mi povedlo pro můj notebook zazáplatovat, první oprava funguje pro všechny verze (v6.1-6.18), druhá oprava funguje jen do verze v6.11. Jak to opravit pro novější kernely (v6.14-6.18) zatím nevím.
Říkal jsem si, že nebudu sobec a poprvé v životě jsem zkusil chyby poctivě nahlásit bugzilla.kernel.org. Chápu, že s vágní informací, že občas místo přihlašovacího okna zůstane displej černý, toho mnoho dělat nelze, tak jsem se snažil podrobně popsat, co si myslím, že problémy působí, jak to lze opravit, přiložil jsem i návh patche...
https://bugzilla.kernel.org/show_bug.cgi?id=220905 (https://bugzilla.kernel.org/show_bug.cgi?id=220905)
https://bugzilla.kernel.org/show_bug.cgi?id=220907 (https://bugzilla.kernel.org/show_bug.cgi?id=220907)
No nevypadá, že by moje snaha padla na úrodnou půdu. :'(
Máte stejnou zkušenost?
-
U velkych projektu to cenu nema. Vetsinou po tobe chteji informace, ktere nejsi schopen dodat, pripadne chtej, aby si to reportoval nejakym predepsanym zpusobem, takze je to na tyden prace. Pak zjistis, ze se jedna o duplikat nejakeho 10 stareho problemu, na ktery nikdo od te doby nesahl.
A i kdyby to prijali jako bug, nez to opravi, budes uz pouzivat neco jineho, co treba i funguje, nebo ten HW uz bude davno odepsany, a ty budes resit problemy s jinym HW.
-
Co se vám nezdá? Vždyť tam máte reakci i během vánočních svátků a máte tam napsáno, co s chybou dál dělat.
-
Zkus to poslat na to LKML jak ti tam radi - pokud je to finalni a jsi podepsan, tak to nekdo muze zhodnotit ze mas pravdu s tim fixem a poslat to do vyssich kruhu. Na realne reseni se pouziva bohuzel ten mailing list a postupuje to hierarhicky. Ten webovy bug tracker je jenom tlacharna/diskuzni forum, tam se neresi samotne zaclenovani oprav.
Jako max te muzou poslat do haje :D pamatuji prvni patch - kdyz jsem z cpu nazvu chtel odstranit duplicitni whitespaces, protoze prece chci mit napsany nazev procesoru hezky v ruznych toolech.. a nedopadlo to moc dobre - pry kdyz tam vyrobce dal 8 mezer, tak tam musi byt 8 mezer :D a ze je to pak hnusny, to se nebude resit.
-
Reportovat můžete, ale čím máte starší hardware, tím je menší šance, že se něco fixne. Může to mít smysl. Čím víc lidí reportuje problém, tím možná mu někdo dá vyšší prioritu. Je ale jasné, že někdy podpora musí skončit.
Já osobně mám dost pozitivní zkušenost - mám Lenovo T520 - teď mu bude 15 let. Kernel 6.16 měl rozbitou síťovou vrstvu - nefunkční wifi, a sem tam crashe. Reportoval jsem (a nebyl jsem sám), a 6.17 běží jak víno. Před měsícem jsem instaloval Fedoru na ještě starší Dell D830 - což bude 18 letý počítač, a všechno běží. Počítač je v perfektním stavu, nicméně ty tři roky navíc jsou znát. T520 je více méně v pohode, D830 už se mi zdá pomalá. Hlavně je to ještě poctivý železo - nikam už by se mi ho nosit nechtělo.
-
Zkus to poslat na to LKML jak ti tam radi ...
Poslat přímo návrh patche do kernelu jsem zkusil jednou před mnoha lety, takže už vím, že to sám nedám. Tehdy jsem nad tím strávil týden, přečetl jsem si o jejich zvyklostech co se dalo, bojoval jsem s mail klientem (Seamonkey), aby u plain-text mailů zalamovala řádky tak, jak si představujou... a pořád bylo něco po formální stránce špatně...
-
Upřímně trochu nechápu, proč to řešíš tady. Ten Artem ti opakovaně jasně řekl, co s tím máš udělat - do jakého LKML report poslat + jakým konkrétním maintainerům. Report někde na bugzille vůbec neodpovídá standardním postupům vývoje kernelu.
V prvním kole to vůbec nemusí být hotový commit, prostě jen nahlásíš problém a popíšeš návrh jeho vyřešení. Někdy potřebný patch mail pošle přímo maintainer (a dá tě jako Reported-By či Tested-By), někdy jej bude chtít po tobě - ale nejdříve se s ním/s ostatními domluvíte, jak by ten commit měl vypadat. Má to formální záležitosti, ale jsou na to nástroje a patche zcela běžně proběhnou několik verzí, než jsou v pořádku.
-
U projektů, jejichž workflow je v končící čtvrtině 21. století přes email, už nereportuju nic. Zdravíme Debian (https://nibblestew.blogspot.com/2025/12/an-uncomfortable-but-necessary.html).
-
U projektů, jejichž workflow je v končící čtvrtině 21. století přes email, už nereportuju nic. Zdravíme Debian (https://nibblestew.blogspot.com/2025/12/an-uncomfortable-but-necessary.html).
Ono by bylo hezky mit vse na githubu ci jine management platforme, ale proste je to drahy kdyz to chcete delat procesne spravne, tj "ridit repo jako firmu". Skoda ze neexistuje nejaky OSS support program, co by tem zajimavym projektum nabidnul stejnou uroven jako placeny github, ale zadaco.
-
GitHub nebo GitLab zdarma mají mnohem lepší uživatelský komfort než ty Debianí issues, dle mého názoru.
-
U projektů, jejichž workflow je v končící čtvrtině 21. století přes email, už nereportuju nic. Zdravíme Debian (https://nibblestew.blogspot.com/2025/12/an-uncomfortable-but-necessary.html).
Nezpomínej, že tyhle projekty mají spoustu unix greybeards typu RMS, kteří mají specifické potřeby: Email má každý, ne každý ale přežije účet u Microsoftu a souhlasení s jejich podmínkami, aby mohl používat Github. Tomu se říká inkluze. ;D
Ono by bylo hezky mit vse na githubu ci jine management platforme, ale proste je to drahy...
Není to drahý. Pokud nabídka veřejných repozitářů zdarma nevyhovuje protože nějaké limity nebo něco, tak třeba GitLab CE je zdarma i self-hosted a bez limitů. Nebude to mít nějaké advanced fičury co má placená verze, ale email nemá vůbec nic. A projekt typu Debian, který stejně má server s git repozitáři, si tam ten webový frontent opravdu přidat může. A malé projekty to nemusí řešit, protože se vlezou do limitů těch veřejných repozitářů zdarma. Kdyby chtěli.
-
Zdravím root.cz a děkuji za opravu chyby ohledně častého random odhlašování ke kterému občas dochází i při odesílání komentáře a ten tak nenávratně zmizí... :) Stejně tak oceňuji vyřešení absurdního mixéru komentářů pod články, které se pro neprominentní uživatele objevují v náhodném pořadí...
-
Pochybuji, že by komunita kernelu nebo debianu kývla na provoz tak důležité infrastruktury u komerčního subjektu, který kdykoliv může svou činnost ukončit či službu zrušit.
Komunikační nástroje debianu neznám, ale kernel má poměrně širokou infrastrukturu postavenou nad emaily (např. klíčový https://patchwork.kernel.org/project/linux-media/list/ ), které to dost usnadňují. Neboť jsou všechny maily na více místech archivované a indexované, není takový problém v tom historicky vyhledávat. Samozřejmě to vyžaduje určitě nastavení mailového klienta, ale lze předpokládat, že ten, kdo chce posílat patche do kernelu, je schopen si to zařídit (např. https://nickdesaulniers.github.io/blog/2017/05/16/submitting-your-first-patch-to-the-linux-kernel-and-responding-to-feedback/ )
-
Zdravím root.cz a děkuji za opravu chyby ohledně častého random odhlašování ke kterému občas dochází i při odesílání komentáře a ten tak nenávratně zmizí... :)
Addon na historii odesílání formulářů v prohlížeči je hodně užitečný i na jiných webech. Samozřejmě mluvím o PC, v mobilu nevím.
-
Pochybuji, že by komunita kernelu nebo debianu kývla na provoz tak důležité infrastruktury u komerčního subjektu, který kdykoliv může svou činnost ukončit či službu zrušit.
No, zatím na druhé straně barikády firmy běžně závisí jedna na druhé. A svět neshořel. Takže tím to asi úplně nebude. Navíc GitLab CE (Community Edition) má otevřené zdrojáky pod MIT licencí. Pokud si tu CE rozjedou (self-hosted), tak i kdyby GitLab zavřel krám nebo CE zrušil, tak to není fatální problém: Budou mít spoustu času na přechod. Nebo se někdo ujme forku.
lze předpokládat, že ten, kdo chce posílat patche do kernelu, je schopen si to zařídit
V téhle větě se schovává ten důvod. Kombinace tradicí, elitismu, bariér které jsou (byť jen podvědomě) stavěné na odradění dostatečně nemotivovaných a fantismu. Musíš projít naším zasvěcovacím rituálem, jinak si s tebou kuličky cvrnkat nebudem. A to neříkám kvůli nějakému zapšknutí, já svůj patch úspěšně a bez nějakých velkých problémů do jádra kdysi dostal a těm projektům držím palce.
Ale přijde mi, že postupně řežou větev, protože největší skupina, co se s tím je ochotná crcat, jsou lidi, co to dělají v rámci své práce. Procházet tím kvůli nefatálnímu problému ve svém volném čase nebude ani většina těch, co by toho jinak byli schopní. A co je mnohem horší, než záviset na nějakém komerčním subjektu s provozem služby? Záviset na tom, že ten komerční subjekt dotuje vývoj toho FOSS projektu časem svých zaměstnanců.