Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
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?
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/
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.