pico-usb-wifi je open source firmware pro Raspberry Pi Pico W, který jej promění v USB Wi-Fi adaptér. Po připojení k počítači se objeví jako zařízení USB CDC-NCM.
Americká společnost Google ze skupiny Alphabet bude muset podle nových požadavků Evropské unie umožnit společnosti OpenAI i dalším konkurentům v oblasti umělé inteligence (AI) a internetových vyhledávačů přístup ke svým službám. Ve svém rozhodnutí o tom včera informovala Evropská komise (EK). Opatření má zajistit dodržování pravidel, jejichž cílem je omezit v EU tržní sílu velkých technologických firem. Google s tím nesouhlasí.
… více »Nové verze webových prohlížečů Chrome a Firefox jsou vydávány každé 4 týdny. Aktuální verze Chrome je 150. Aktuální verze Firefoxu je 152. V březnu bylo oznámeno, že od září přejde Chrome na dvoutýdenní cyklus vydávání verzí. To by znamenalo, že Chrome v číslování verzí Firefox brzy přeskočí. Vývojáři Firefoxu proto také od září přecházejí na dvoutýdenní cyklus vydávání verzí. :-)
Microsoft Comic Chat (Wikipedie), tj. grafický IRC klient z devadesátek, který převáděl konverzace na IRC do podoby komiksových panelů, a který zpopularizoval font Comic Sans, je dnešním dnem open source. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Byla vydána (𝕏) nová verze 26.7 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense postavený na FreeBSD. Kódový název OPNsense 26.7 je Xenial Xenops. Přehled novinek v příspěvku na fóru.
Na Seznam nepovolených internetových her (Wikipedie) se k 13. 7. 2026 dostala predikční platforma Polymarket.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 167 (pdf) a Hello World 30 (pdf).
Byla vydána nová verze 3.22.0 grafického vývojového prostředí a platformy Gambas (Wikipedie) založené na interpretru programovacího jazyka Basic s rozšířením o objektově orientované programování. Přehled novinek v poznámkách k vydání. Zdrojové kódy jsou k dispozici na GitLabu.
FreeBSD odstranilo poslední GPL kód ze základního systému. Konkrétně dpv, libdpv, libfigpar a dialog. Instalátor před čtyřmi lety přešel z dialogu na bsddialog.
Sociální síti 𝕏 (dříve Twitter) má dnes 20 let. Pro veřejnost byla zpřístupněna 15. července 2006.
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
.