Po 20 letech a 17 otevřených (open source) krátkých filmech Blender Studio oznámilo plán na svůj první celovečerní film. Cílem samozřejmě není jenom nový otevřený film, ale především vývoj a vylepšení otevřených nástrojů pro spolupráci napříč celým procesem a vytvoření otevřené příručky (playbook) pro filmovou produkci ve velkém měřítku s informacemi, které jsou obvykle dostupné pouze uvnitř komerčních studií, a pomoci tak nezávislým tvůrcům překonat technické a organizační bariéry.
Byla vydána nová verze 26.6.25 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Apple bez varování odstranil ze svého obchodu sociální síť VKontaktě i další aplikace skupiny VK, jako je VK Music nebo VK Video [Novinky.cz].
V dubnu loňského roku představený poštovní klient Notion Mail bude 22. září ukončen.
Konference OpenAlt 2026 hledá přednášející. Proběhne o víkendu 7. a 8. listopadu na půdě Fakulty informačních technologií VUT v Brně. Témata konference jsou: Otevřený a svobodný software, IoT a Hnutí tvůrců, Vzdělávání, Bezpečnost a soukromí, Otevřená společnost, komunity a data, OpenMobility a další.
Společnosti OpenAI a Broadcom oznámily čip optimalizovaný pro AI pojmenovaný Jalapeño.
Deno (Wikipedie), běhové prostředí (runtime) pro JavaScript, TypeScript a WebAssembly, bylo vydáno v nové verzi 2.9. Hlavní novinkou je deno desktop pro převod Deno projektu na desktopovou aplikaci. Jedná se o alternativu k frameworkům Electron nebo Tauri.
Od zítra jsou Datové schránky oficiálně na nové adrese datovka.gov.cz. Adresa mojedatovaschranka.cz zůstává funkční do 27. srpna 2026, následně budou uživatelé automaticky přesměrováni na datovka.gov.cz.
Dolphin (Wikipedie), tj. open source multiplatformní emulátor herních konzolí GameCube a Wii od Nintenda, byl vydán ve verzi 2606. S podporou Game Boy Playeru.
Vasudeva Kamath představil utilitu debvulns, alternativu k nativní utilitě debsecan, pro výpis zranitelností v Debianu. Navíc má především možnost výstupu ve strukturovaných formátech JSON a CSV. V plánu je exportér pro Prometheus.
Různé drobnosti a užitečnosti na které narazím nebo sám vytvořím. Primárně se zaměřuji na věci, které mohou být zajímavé a užitečné pro ostatní uživatele GNU/Linuxu či typografického systému TeX, občas se tu ale určitě vyskytne i něco z úplně jiného soudku, např. z oblasti bezpečnosti apod.
Nevíte někdo, co se to dneska dělo s kernelem Linuxu? Podle Kernel.org vyšlo dnes do této chvíle 7 (slovy „sedm“!) opravných verzí. Ze stabilního jádra 2.6.23.1 tak máme v této chvíli stabilní jádro 2.6.23.8. Tohle mi na stabilní větvi nepřipadá jako ideální stav.
Vydávání vypadalo takto:
Date: Fri Nov 16 08:19:12 2007 -0800
Linux 2.6.23.2
Date: Fri Nov 16 08:24:58 2007 -0800
Linux 2.6.23.3
Date: Fri Nov 16 08:36:42 2007 -0800
Linux 2.6.23.4
Date: Fri Nov 16 09:27:48 2007 -0800
Linux 2.6.23.5
Date: Fri Nov 16 09:33:58 2007 -0800
Linux 2.6.23.6
Date: Fri Nov 16 09:43:31 2007 -0800
Linux 2.6.23.7
Date: Fri Nov 16 10:14:27 2007 -0800
Linux 2.6.23.8
Už vidím, jak tohle rozmáznou na anti-linuxových serverech. :-/
Update: Není to chyba, ale vlastnost.
Lots of stable kernel updates. Tímto se autorům omlouvám.
Chtěl jsem to sem připsat ještě včera v noci, ale ÁBíČko bylo nedostupné. :-/
Tiskni
Sdílej:
No že se chyby opravují, to je jasné. (Díky všem, kteří to dělají. Patří jim mé srdečné díky.) Proč ale musí na stabilní větvi vyjít během několika hodin sedm opravných verzí? Od vydání 2.6.23.1 uplynulo skoro pět týdnů. Snad by se tedy dalo 2.6.23.2 vydat ještě o pár hodin později, ale se všemi opravami najednou, ne?
Podle me cela rada uz od sveho vzniku vsechno mozne (progresivni, inovativni, apod.) jen ne "stabilni"...
To je obvykle starost vývojářů distribuce.Protoze vyvojari v distribucich nemaji nic lepsiho na praci, nez furt dokola opravovat skody napachane aktualizaci jadra. A ty rady, aby se tyhle moduly zaclenily do jadra, ty jsou taky k nezaplaceni. Kdyz uz se to nejakou nestastnou nahodou nekomu povede, tak to dopadne tak, ze po vsech "opravach" kodu obsahuje x-nasobek chyb oproti kodu, ktery byl mimo jadro. Protoze dosavadni vyvojari, co danou vec po leta vyvijeli, jsou evidentne nesvepravni pitomci, takze na jejich namitky a zduvodneni, proc je neco udelano tak, jak je, a ne tak, jak by panove od kernelu chteli, neni potreba brat zretel. Nedavny priklad je treba ivtv.
Nebylo GPIO označené za obsolete už docela dlouho?Jiste, nejlepsi je pouzivanou vec smazat a na uzivatele hodit bobek. On tam ten kod totiz hrozne prekazel a bez jeho smazani by se kernel nepohnul z mista.
Už ani nepamatuju dobu, kdy gpio obsolete nebylo - víc než rok to v takovém stavu bylo. Jako náhrada je teď dev/event, byl dostatek času na přechod.Nebylo GPIO označené za obsolete už docela dlouho?Jiste, nejlepsi je pouzivanou vec smazat a na uzivatele hodit bobek. On tam ten kod totiz hrozne prekazel a bez jeho smazani by se kernel nepohnul z mista.
Už ani nepamatuju dobu, kdy gpio obsolete nebylo - víc než rok to v takovém stavu bylo. Jako náhrada je teď dev/event, byl dostatek času na přechod.Jiste, ono to sice nefunguje, ale na to sere pes. Hosi dekujem!
lircd-0.8.3pre1[21753]: lircd(cph06x) ready lircd-0.8.3pre1[21753]: accepted new client on /dev/lircd lircd-0.8.3pre1[21753]: could not get hardware features lircd-0.8.3pre1[21753]: this device driver does not support the new LIRC interface lircd-0.8.3pre1[21753]: major number of /dev/input/event5 is 13 lircd-0.8.3pre1[21753]: LIRC major number is 61 lircd-0.8.3pre1[21753]: check if /dev/input/event5 is a LIRC device lircd-0.8.3pre1[21753]: caught signal /etc/init.d/lircmd[21762]: start-stop-daemon: /usr/sbin/lircmd died /etc/init.d/lircmd[21742]: ERROR: lircmd failed to start
Pokud vím, bylo to především tak, že pánové od lirc se několik let sveřepě bránili návrhům na začlenění ovladače do jádra, takže upřímně řečeno, dobře jim takNeni nad to zjistit si informace, nez tady zase plknes nejakou nebetycnou kravinu... http://git.wilsonet.com/linux-2.6-lirc.git/
Jako obsolete (a obvykle na dlouhou dobu) jsou takové věci označeny hlavně proto, aby se lidé, kteří ještě něco takového potřebují, ozvali. Pokud se rok neozvou tak, světe div se, mají smůlu.
Protoze dosavadni vyvojari, co danou vec po leta vyvijeli, jsou evidentne nesvepravni pitomci, takze na jejich namitky a zduvodneni, proc je neco udelano tak, jak je, a ne tak, jak by panove od kernelu chteli, neni potreba brat zretel.Viděl jsem už pěknou řádku externě vyvíjených modulů a na téměř všech je vidět, že jejich základy pocházejí odkudsi z dávnověku, kdy ještě spousta věcí v jádru fungovala jinak, a od té doby jsou pouze záplatovány, aby chodily s novějšími kernely. Pitomost bych nikomu nepřisuzoval, ale jaksi málokdo, kdo není přímo zapojený do vývoje jádra, dokáže při starání se o své ovladače ještě sledovat docela zběsilé tempo vývoje zbytku jádra. Při review kódu před začleněním do jádra také často vyjdou najevo nejrůznější bugy (například v základech shnilé zamykání v ReiserFS 4) nebo nepřenositelnost (ne každý ví, na co se lze spolehnout obecně a na co jen na i386). Proto si myslím, že začleňování do jádra většině driverů prospěje. Výjimky se samozřejmě najdou všude, ale podle nich bych nesoudil na funkčnost celého systému.
Některé distribuce, jako SUSE, to vzdaly a přestaly podporovat karty na tom čipsetu úplně. Takže v SUSE 10.1 to fungovalo, provedete upgrade na SUSE 10.2, těšíte se, co bude nového a vylepšeného, a ona zatím wifi přestalo fungovat úplně.
Driver pro Ralink wi-fi v OpenSuSE 10.2 je, je jen potřeba nainstalovat příslušný balíček.
wlan-kmp-default, v 10.3 rt2x00-kmp-default.
Pokud by se vrtali jen v implementaci a garantovali API, alespoň po nějakou nezanedbatelnou dobu, byl bych spokojený.Možná nebyl, když by se brzy ukázalo, že nějaký nový driver nelze do jádra přidat bez změny API
Mezi KDE a jádrem je bohužel ten podstatný rozdíl, že zatímco KDE žije ve svém vlastním světě, kde si volí axiomy, jádro se musí umět přizpůsobit stále se vyvíjejícímu hardwaru.
Jistě, problém lze obejít tak, že zavedete kopii původního API a změníte jen tu, ale to je, slušně řečeno, čuňačina a cesta, ačli dlážděná úmysly z nejčistších, vedoucí kamsi pod zem.
Tohle jsem četl kdesi na živě a musím říct, že to ten dotyčný vystihl dokonale (dokonce to byl Windowsák). Takže si myslím, že WXP nebudou jediným problémem Vist
.