Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za březen (YouTube).
ESP-IDF (Espressif IoT Development Framework), tj. oficiální vývojový framework pro vývoj aplikací na mikrokontrolérech řady ESP32, byl vydán v nové verzi 6.0. Detaily na portálu pro vývojáře.
DeepMind (Alphabet) představila novou verzi svého multimodálního modelu, Gemma 4. Modely jsou volně k dispozici (Ollama, Hugging Face a další) ve velikostech 5-31 miliard parametrů, s kontextovým oknem 128k až 256k a v dense i MoE variantách. Modely zvládají text, obrázky a u menších verzí i audio. Modely jsou optimalizované pro běh na desktopových GPU i mobilních zařízeních, váhy všech těchto modelů jsou uvolněny pod licencí Apache 2.0. Návod na spuštění je už i na Unsloth.
Cursor (Wikipedie) od společnosti Anysphere byl vydán ve verzi 3. Jedná se o multiplatformní proprietární editor kódů s podporou AI (vibe coding).
Průkopnická firma FingerWorks kolem roku 2000 vyvinula vícedotykové trackpady s gesty a klávesnice jako TouchStream LP. V roce 2005 ji koupil Apple, výrobu těchto produktů ukončil a dotykové technologie využil při vývoji iPhone. Multiplatformní projekt Apple Magic TouchstreamLP nyní implementuje funkcionalitu TouchStream LP na současném Apple Magic Trackpad, resp. jejich dvojici. Diskuze k vydání probíhá na Redditu.
Byla vydána nová verze 10.3 sady aplikací pro SSH komunikaci OpenSSH. Přináší řadu bezpečnostních oprav, vylepšení funkcí a oprav chyb.
Cloudflare představil open source redakční systém EmDash. Jedná se o moderní náhradu WordPressu, která řeší bezpečnost pluginů. Administrátorské rozhraní lze vyzkoušet na EmDash Playground.
Bratislava OpenCamp 2026 zverejnil program a spustil registráciu. Štvrtý ročník komunitnej konferencie o otvorených technológiách prinesie 19 prednášok na rôzne technologické témy. Konferencia sa uskutoční v sobotu 25. apríla 2026 v priestoroch FIIT STU v Bratislave.
Na iVysílání lze zhlédnout všechny díly kultovního sci-fi seriálu Červený trpaslík.
Společnost Valve aktualizovala přehled o hardwarovém a softwarovém vybavení uživatelů služby Steam. Podíl uživatelů Linuxu dosáhl v březnu 5,33 % (Windows -4,28 %, OSX +1,19 %, Linux +3,10 %). Nejčastěji používané linuxové distribuce jsou Arch Linux, Linux Mint a Ubuntu. Při výběru jenom Linuxu vede SteamOS Holo s 24,48 %. Procesor AMD používá 67,48 % hráčů na Linuxu.
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.

Tiskni
Sdílej: