Ve středu 29. dubna 2026 se v pražské kanceláři SUSE v Karlíně uskuteční 7. Mobile Linux Hackday, komunitní setkání zaměřené na Linux na mobilních zařízeních, kernelový vývoj i uživatelský prostor. Akce proběhne od 10:00 do večerních hodin. Hackday je určen všem zájemcům o praktickou práci s Linuxem na telefonech. Zaměří se na vývoj aplikací v userspace, například bankovní aplikace, zpracování obrazu z kamery nebo práci s NFC, i na úpravy
… více »LilyPond (Wikipedie) , tj. multiplatformní svobodný software určený pro sazbu notových zápisů, byl vydán ve verzi 2.26.0. Přehled novinek v aktualizované dokumentaci.
Byla vydána nová verze 11.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 237 vývojářů. Provedeno bylo více než 2 500 commitů. Přehled úprav a nových vlastností v seznamu změn.
Společnost SpaceX amerického miliardáře Elona Muska oznámila, že si zajistila opci buď na akvizici startupu Cursor za 60 miliard dolarů (přes 1,2 bilionu Kč) do konce letošního roku, nebo na zaplacení deseti miliard dolarů za nové partnerství s touto firmou zabývající se generováním kódů. SpaceX se dále prosazuje na lukrativním trhu s vývojářskými nástroji pro umělou inteligenci (AI). Cursor, startup zabývající se prodejem modelů AI pro
… více »Díky AI modelu Claude Mythos Preview od společnost Anthropic bylo ve Firefoxu nalezeno a opraveno 271 zranitelností.
Byla vydána nová verze 2.54.0 distribuovaného systému správy verzí Git. Přispělo 137 vývojářů, z toho 66 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 13.0. Přehled novinek v aktualizované dokumentaci a na YouTube. Stalo se tak na konferenci GrafanaCON 2026.
Na YouTube proběhl Framework [ Next Gen ] Event 2026. Společnost Framework představila nový Framework Laptop 13 Pro, vylepšení Framework Laptopu 16 a OCuLink Dev Kit pro připojení vysoce výkonných periferií jako jsou eGPU a bezdrátovou klávesnici s integrovaným touchpadem Framework Wireless Touchpad Keyboard.
Byl vydán Mozilla Firefox 150.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 150 bude brzy k dispozici také na Flathubu a Snapcraftu.
Byl představen (reddit, 𝕏) webový prohlížeč Brave Origin. Jedná se webový prohlížeč Brave bez VPN, krypto peněženky a odměn, tj. bez funkcí, ze kterých je vývoj Brave financován. Stojí jednorázově 59,99 dolarů. Verze pro Linux je zdarma.
V úvaze pojmenované The SourceForge
Hegemony se zhrzený uživatel ptá, co by se stalo, kdyby provozovateli
SF, firmě VA Software, vyschly
zdroje, ze kterých financuje chod těchto stránek. Říkám zhrzený, protože
podobně neveselé myšlenky získal po té, co byl svými "spolupracovníky" zbaven
administrátorských práv k projektu, do kterého přispíval.
Je docela dobře možné, že ten člověk má pravdu, jeho projekt byl skutečně "unesen" (dobře, takový překlad nedává smysl, ale musel jsem se podělit o termín "hijacked project") a ironický podtón prvního odstavce vůbec není na místě. V tom však nevězí to podstatné.
Pokud by se jednoho dne zavřely na SF dveře a nikdo by už nezískal zpět to, co tam kdy vložil, mělo by to s velkou pravděpodobností dost negativní vliv na vývoj všech linuxových distribucí - jinými slovy, vývoj některých (důležitých) komponent by se alespoň na přechodnou dobu zastavil.
Bylo by snadné najít náhradu? Pár alternativ tu je (Berlios, Savannah), ale žádná nedosahuje ani zdaleka rozměrů SF. Nehledě na to, že na větší příliv projektů nejsou připraveny. A to ještě záměrně opomíjím provázanost Savannah s GNU - i když tu je i non-GNU Savannah...
A i kdyby se místo našlo, jak těžké by bylo navázat na vývoj bez údajů v databázi (chyby, mailové konference, historie revizí, ...)? To ovšem předpokládá úplné vyřazení SF ze dne na den. A tak katastroficky by se asi situace nevyvíjela.
Originál článku najdete na kuro5hin.org.
Poměrně nedávno proběhla mezi vývojáři jádra (a samozřejmě posléze i mezi obyčejnými smrtelníky) debata o tom, jestli je správné z kernelu odstranit kód určený k natažení binárního ovladače. Nejdřív troška historie:
Dost dlouhou dobu byl součástí linuxového jádra ovladač pwc, který kromě základní podpory Philips a Logitech web-kamerek umožňoval i využití binárního ovladače pwcx. Pwcx je/byl ovladač zajišťující plnou funkčnost těchto kamerek (jde o (de)kompresi videosignálu). Bez pwcx je možné kamerky používat, ale stojí to za starou belu. Pwcx je však pouze binární ovladač, tzn. ne pod GPL, a proto nemůže být součástí jádra. Byl tedy dodáván zvlášť a uživatel se mohl rozhodnout, jestli jej s pomocí háčku v pwc využije nebo ne.
Pwcx je binární proto, že Philips po jeho vývojáři požadoval podepsání NDA (Non-Disclosure Agreement = Dohoda o nevyzrazení). Hardwarové specifikace se tedy neměly dostat na veřejnost (jak se později zjistilo, tato NDA už nějakou dobu neplatí - vypršela; autor však i nadále odmítá zveřejnit specifikace, protože má pocit, že by tím ztratil důvěru Philipsu a zároveň tím ukázal vývojáře jádra před ostatními firmami jako nedůvěryhodné).
Správce USB subsystému v jádře, Greg KH, se rozhodl z ovladače pwc odstranit kód, který sloužil k natažení pwcx. To rozzlobilo autora pwc(x), protože to považoval za rozhodnutí fundamentalistické, které nic nevylepší, ale naopak znevýhodní uživatele - nebudou již moci pomocí pwc využívat pwcx. Greg argumentoval tím, že kód, který v jádře neslouží ničemu jinému než externímu proprietárnímu ovladači, nemá v kernelu co dělat. A rozjela se dosti ostrá diskuze o tom, kde ideologická korektnost hraničí s prachsprostým omezováním možnosti volby uživatele jaký software používat.
Craig (autor pwc) se tedy namíchl a požádal o odstranění veškerého pwc kódu. Když už tam nesmí být možnost natáhnout binární ovladač, nemá tam být nic, protože samo o sobě je to jen zmrzačená chudinka, která toho moc nesvede.
Žádost o odstranění kompletního pwc je do určité míry pouhopouhé gesto, protože kdokoliv může ten kód vzít a (protože je licencovaný GPL) znovu do jádra vložit. Otázkou však je, jestli by se našel někdo, kdo by byl ochoten se toho kódu ujmout coby správce.
Z tohoto vývoje vyplývá několik otázek:
Zde jsou různé zdroje:
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Jak souvisí V4L tím, jakou kompresi používá nějaká webkamera ?
No treba tak, ze V4L je _standardni_ rozhrani, jak dostat _standardni_ obrazek z nejakeho videozarizeni. To by potom kazdy prehravac/recorder mel podporovat vsechny kamery?!?! A kazdy audio soft by mel podporovat pokud mozno vsechny zvukovky, ze... To bychom potom vlastne zadne drivery nepotrebovali... A pokud mozno zadny OS. ;)
No a na to AC jasně odpověděl, že jestliže ve V4L chybí možnost zařadit do řetězce zpracování toho streamu HW závyslý dekodér, tak že má udělat V4L3. Jestli ty takovou odpověď pocvažuješ za jízlivost, tak jsi prostě paranoidní.
Pokud delam ovladac kamery a pro jeho zarazeni po mne nekdo chce predelat cele API pod nim, ktere sam (dost nestastne) navrhnul... no ... nevim, zda je to jizlivost, ale rozhodne by mne to kapku zarazilo... 
No tak já teda mám jasno, co bych chtěl v jádře já. V4L3 s možností zavádět do dekódovacího řetězce HW závislé moduly. Ty ne? Tak to jsi jdi prasit jiné jádro.
No, tak tohle bych chtel taky. A kdo ne, ze?
Teď jste to obrátil úplně na hlavu ! Používáte můj argument, abyste obhájil své tvrzení, proti čemu přesně tenhle argumet stojí.
Eh? Ja rikam: v kernelu maji byt ovladace kamery (at uz binarni nebo OS), ktere ze zarizeni dostanou standardni cokoli, i kdyz to zarizeni to posila v jinem, proprietarnim formatu. To je to, co rika muj argument nahore a taky je to presne ten duvod, proc mame ovladace. Ty zajistuji na jedne strane standard (API) a na druhe se snazi pokryt ruzna zarizeni. Pokud budou ovladace zvukovek v kernelu a ne v software (a zaplatpanbu tomu tak je), staci pridat ovladac do kernelu a ne do vsech audio SW. Podobnych primeru lze vymyslet spoustu.
V tom si odporuješ. To "cokoliv" totiž nikterak "standardní" není. Ostatně, mohu tě citovat:
bez pwcx lezou z kamerky v hires/hifps modech komprimovana data, na ktere _zadny standard neexistuje_,Je to jednoduché: Philips chce uzavřený formát, proto vyvine nějakou zbastleninu, která skutečně žádnému standardu neodpovídá. Chtějí-li to lidé používat, musí mít jejich binární ovladač. Binární ovladače nemají v jádře co dělat -- a ani kód, který by umožňoval jejich použití. Kernel je svobodný a neměl by obsahovat něco, co slouží pouze a výhradně nesvobodnému kódu. A dříve než řekneš, že to je _pouze_ ideologie, viz moje odpověď z počátku této diskuze:
---------Samozřejmě, že i to ideologické hledisko je důležité, protože ta pravidla je potřeba dodržovat.
Takže ideálním řešením by bylo to ponechat mimo jádro jako např. ty stále zmiňované ovladače od nVIDIE.Tím už se však opakuji.
Pod pojmem 'standardni cokoli' si zkuste predstavit RGB, YUV, atd. To, ze to Phillips nepodporuje je logicke - zkuste si spocitat, kolik dat se vleze do bandwidthu USB1.1... Podezirat Phillips, ze neco chce jenom ztezovat je mylna - viz funkce modulu pwc - z kamery dostane raw data, ktera se vicemene podobaji YUV. Proste to jinak udelat nejde.
Pro mne je nejlepsi reseni nasledujici (vedle ponechani statusu quo a uplne otevreni pwc[x]): odstranit ovladac _uplne_ z vanilla jadra (v jadre opravdu nema co delat zmrvenej kod od GKH & spol.) a pokracovat na vyvoji oddelene vcetne vsech hooku.
Mimochodem, zeptam se: kolik lidi v tehle diskuzi vubec pwc[x] pouziva? 
Uvedomte si, ze dekompresi videa delaji _vsechny_ (USB1.1 prirozene) webcamove ovladace v jadru. Jinak to ani nejde. pwc[x] se lisi jenom tim, ze ta dekomprese je closed source. Jinak nicim.
To, ze je linux monolit, neznamena, ze nemuze prejimat i neco z mikrokernelu.
Jinak to ani nejde. pwc[x] se lisi jenom tim, ze ta dekomprese je closed source.No a prave o to jde. Kdyz neco bezi s pravy operacniho systemu, tak treba ja chci mit tu moznost podivat se na zdrojaky. Je to prakticka vec, ne ideologicka. Nekomu se to mozna zda obracene, tak pro nej to asi prakticka vec neni.
Napadlo vas treba, jak by tim vasim zpusobem vypadal adresar /dev? Tisice souboru pro tisice ruznych HW. Bajecny...
No a proc ne? Uzivatel prece nepotrebuje vypisovat obsah adresare /dev, ne? Staci mu znat nazev souboru zarizeni. Jinak tisice to opravdu nebudou. Mame prece devfs/udev, ktery vytvari jen potrebne soubory.
To je chválihodné. Avšak Craig podmiňuje práci na pwcx tím, že v jádře bude onen háček.
Coz docela chapu, vzhledem k tomu, ze na tom stravil 3 roky zivota... Odvedl kus dobre prace a kvuli nejake ideologii po nem chteji, aby si praci zdvojnasobil - pracoval na orezane official kernel verzi (samozrejme, muze prijit jiny maintainer, o tom vsak dost pochybuji) a jeho plne funkcni verzi. Byl bych vytocen uplne stejne. Uvedomte si, ze kdyz bude modul uplne mimo kernel, bude se treba moci zkompilovat zvlast (jako nVidia, spca50x a dalsi) a ne polosilene patchovat orezana verze v kernelu verzi plnou.
Hmm, není to trochu namyšlené? Proč zrovna v jeho případě by to měla být výjimka? A pokud by někdo řekl: "A proč ne?", tak viz jeden z mých komentářů výše (odpověď na otázku, jestli bude bez toho háčku jádro lepší).
No, mozna bychom meli uvest na pravou miru, co ten hacek vlastne dela:
PWC exports a function outside of the kernel, a so-called hook. Jde pouze o zjisteni adresy jedne funkce - neni to nejake polosilene API. Nemluve o tom, ze pwcx je volano z jadra 2ma slovy dvema funkcemi - cely system pwc/pwcx je udelan nejlepe (nejvic minimalisticky vzhledem ke kernel policies), jak to jde. A rikat, ze 'bez exportu jedne funkce bude jadro lepsi' je ponekud posetile tvrzeni.Hmm, není to trochu namyšlené? Proč zrovna v jeho případě by to měla být výjimka? A pokud by někdo řekl: "A proč ne?", tak viz jeden z mých komentářů výše (odpověď na otázku, jestli bude bez toho háčku jádro lepší).
Mozna to bude znit divne, ale IMHO 99% open source vyvojaru to dela pro vlastni egomasaz (mysleno v dobrem). Chteji, aby jejich produkt pouzivali uzivatele a maji s toho radost, ze jim treba nekdo podekuje/pochvali. No a Nemosoft se po 3 letech prace dostal mezi ty vyvovelene developery, jejichz prace je zverejnovana v kernelu. Ted mu LKDs rekli, ze jeho praci zprzni nebo ze toto postaveni ztrati. Zcela logicky se nechtel podepsat pod zprznenou verzi SW a v ramci sve jesitnosti rekl 'Bud vsechno, nebo nic.' (ano, uznavam Nemosoft je jesitny - ale o nic vic nez spousta dalsich vyvojaru). Plne toto rozhodnuti chapu a v jeho situaci bych se zachoval stejne a myslim, ze nejen ja.
To není ideologické rozhodnutí, nýbrž praktické. Těžko mít stabilní ABI při tempu, kterým se vývoj jádra ubírá. Kolika lidem by se líbilo, kdyby byl vývoj každou chvíli limitován nutností ohlížet se na nějaký proprietární ovladač?
Cituji Linuse:
- I _want_ people to expect that interfaces change. I _want_ people to know that binary-only modules cannot be used from release to release. I want people to be really really REALLY aware of the fact that when they use a binary-only module, they tie their hands. Note that the second point [vyse uvedeny] is mainly psychological, but it's by far the most important one. http://www.uwsg.iu.edu/hypermail/linux/kernel/9902.1/0012.htmlBtw, pro podobně sprostá slova není v tomto prostředí nikdy důvod. Vyhni se, prosím, jejich používání.
Opravdu jsem nenasel lepsi primer...Celé jádro je totiž na této ideologii postavené.
Tohle je to, co jsem chtel slyset. Jak jsem rikal na zacatku, je boj ideologii, tot vse. Ja osobne se stavim na stranu Nemosoftu, jini na stranu druhou. Ovsem cely tenhle problem zduvodnovat 'lepsim kernelem', 'porusenim GPL' (coz se tusim v LKML taky nekdo pokousel) je zcestny.
Připadá ti, že to všechno říkal škodolibě a naschvál?
Nevim, mozna ctu mezi radky jenom ja, ale I _want_ people to know that binary-only modules cannot be used from release to release. mne nepripada nijak jinak nez zly umysl ci donucovaci prostredek.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz