Google Chrome 137 byl prohlášen za stabilní. Nejnovější stabilní verze 137.0.7151.55 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 11 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Byl vydán AlmaLinux OS 10 s kódovým názvem Purple Lion. Podrobnosti v poznámkách k vydání. Na rozdíl od Red Hat Enterprise Linuxu 10 nadále podporuje x86-64-v2.
Byl vydán Mozilla Firefox 139.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 139 je již k dispozici také na Flathubu a Snapcraftu.
Byly publikovány výsledky průzkumu mezi uživateli Blenderu uskutečněného v říjnu 2024. Zúčastnilo se více než 7000 uživatelů. Téměř 93 % z nich například používá uživatelské rozhraní v angličtině.
Lukáš Růžička v článku RamaLama aneb vyháníme lamy na vlastní louku na MojeFedora.cz představuje open source nástroj RamaLama umožňující spouštět jazykové modely v izolovaných OCI kontejnerech, a to bezpečně, bez potřeby mít root přístup k počítači, s podporou GPU či CPU a bez zbytečných obtížností kolem.
Byl vydán Sublime Text 4 Build 4200. Sublime Text (Wikipedie) je proprietární multiplatformní editor textových souborů a zdrojových kódů. Ke stažení a k vyzkoušení je zdarma. Pro další používání je nutná licence v ceně 99 dolarů. Spolu se Sublime Merge je cena 168 dolarů.
Multiplatformní open source voxelový herní engine Luanti byl vydán ve verzi 5.12.0. Podrobný přehled novinek v changelogu. Původně se jedná o Minecraftem inspirovaný Minetest v říjnu loňského roku přejmenovaný na Luanti.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 25.5. Přehled novinek v Changelogu.
Po 25 letech s číslem 329 končí linuxový časopis Linux Format (Wikipedie, reddit, 𝕏).
Immich z balíčků open source aplikací FUTO je alternativa k výchozím aplikacím od Googlu a Applu pro správu fotografií a videí. Umožňuje vlastní hosting serveru Immich. Zdrojové kódy jsou k dispozici na GitHubu pod licencí AGPL-3.0.
Následující obsah je © KernelTrap.
24. říjen, originál
Tenhle -rc patří mezi největší -rc v historii. Je obrovský. Obvykle má zkomprimovaný -rc1 diff kolem 3 - 5MB, občas jsou i menší a občas mají některé nanejvýš 6 M, nicméně tenhle má "jedenáct" mega. Takto Linus Torvalds ohlásil první release candidate nadcházejícího jádra 2.6.24. Shrnul některé ze změn: Ve zkratce jsme měli nejenom neobvykle velké množství novinek pro x86, ale také tuny nových ovladačů (nejvíc pro bezdrátové síťování, ale to rozhodně není jediné - připojují se dvb, normální drátové sítě, mmc atd.), značné množství záležitostí okolo architektur, souborových systémů, síťování atd.
Jinými slovy, ani nevím, kde začít. Velká a nepřehlédnutelná záležitost je sjednocení x86 a myslím si, že si všichni moc a moc přejeme, aby to nezpůsobilo žádné problémy. Zatím to byla klidná plavba (zaklepat na dřevo). Méně hladké byly změny rozsyp-sesbírej [scatter-gather] v blokové vrstvě, ale ty už jsou doteď snad také v přijatelném stavu. A změny ve VM? Upřímně doufám, že si jich ani nikdo nevšimne. Totéž platí pro nějaké změny ve VFS vrstvě, které ovlivnily v podstatě každý souborový systém (nicméně většinou velmi zřetelným způsobem).
24. říjen, originál
Mohli bychom, prosím, trochu více dokončit tohle začlenění předtím, než zmrazíme 2.6.24? To, co zbylo po arch/i386 a arch/x86_64, je v porovnání se stavem po sloučení jiných architektur noční můra, ptal se Christoph Hellwig, což vedlo Ingo Molnára k sepsání vysvětlující odpovědi: Abychom mohli odpovědět na tuto otázku, je nejprve třeba mít v patrnosti základní problémy s kvalitou kódu, které sjednocená architektura x86 zdědila od i386 a x86_64.
Následně použil skript checkpatch a vytvořil tabulku chyb stylu programování na tisíc řádků zdrojového kódu. V jeho tabulce mělo arch/i386 77,3 chyb na tisíc řádků a arch/x86_64 96,0. Nová sjednocená arch/x86 měla méně - 74,1 - což je ale stále hodně. Je dost zjevné, že kvalita kódu architektur x86_64 a i386 byla před sjednocením ve strašném stavu. Byla řádově horší než jádro jádra [core kernel] a významně horší než několik porovnatelných architektur.
Takže k odpovědi na tvou otázku: plné sjednocení není jednoduchý úkol a rozhodně to není automatické. Kvůli jejich nelogickému a vynucenému oddělení a následné degeneraci se během pěti let strom x86_64 odlišil od stromu i386. V obou architekturách se objevily různé sady problémů s čistotou a různé sady funkcí se zbytečnými rozdíly, které často pokrývají stejnou funkčnost. K tomu všemu se přidává fakt, že 64bitový kód je v horším stavu než 32bitový, takže nemůžeme jen tak vzít 64bitový kód a použít ho jako unifikovaný. 32bitový kód je také používán 8 až 10× častěji než 64bitový, takže žádná "prostě to sjednotíme" cesta neexistuje.
27. říjen, originál
Nedávné hlášení na LKML naznačovalo zlepšení výkonu IO/writeback v nedávno uvolněném jádře 2.6.24-rc1 v porovnání se staršími jádry 2.6.19.2 a 2.6.22.6. Zásluha na tom je přisuzována patchům od Petera Zijlstra. Ingo Molnar reagoval: Wow, opravdu hezké výsledky! Peter ví, jak věci zrychlit :). Pojďme zařadit také jeho další dříve nepřijaté patche :-). Ukázal na několik patchů pro začátek a zavtipkoval: Myslím si, že MM (memory management, správa paměti) by se měl dostat z režimu hlubokého zmrazení vlastností - je tam spousta prostoru ke zlepšení :-/
To jsou vtipy, odpověděl Andrew Morton, do 2.6.24-rc1 jsme zařadili okolo 265 MM patchů: 482 souborů změněno, 8071 vložení (+), 5142 výmazů (-). Spousta z toho byly nové funkce - je jednodušší přidávat než měnit něco, co dlouhodobě funguje, dodal. Peter poznamenal, že z patchů, na které Ingo poukazoval, zrovna pracuje na vylepšování patche pro swapování přes NFS. Brzo ho zašlu znovu... obzvlášť poté, co Linus řekl, že by se mu líbilo mít swap přes NFS. Rik van Riel se vyjádřil o kódu nahrazování stránek: V tuto chvíli mám hotovou jenom základní "instalatéřinu" rozdělené virtuální paměti [split VM] a opravuji v tom nějaké chyby. Ohledně toho v blízké době očekávejte sérii patchů, abyste mohli ten kód projít a říct mi, jak ho trochu víc dotlouct do správného tvaru :-)
27. říjen, originál
Andrew Morton přijal kladně nejnovější verzi subsystému distribuovaného úložiště [distributed storage subsystem] Evgenije Poljakova. Prošel jsem si a znovu přečetl diskuze z posledního měsíce a nevidím důvod, proč bychom neměli začít uvažovat nad začleněním. Potom se zeptal: Jak blízko je to k takovému stádiu? Nahlédnutí do tvého vývojářského blogu naznačuje, že věci se ještě střední rychlostí mění. Evgenij odpověděl:
Dokončil jsem vývoj ukládací vrstvy jako takové, jediná zbývající todo položka je implementace nového algoritmu redundance, ale to nevidím jako významný požadavek, takže pro teď to má malou prioritu. Jako transportní vrstvu pro distribuovaný souborový systém použiji DST, které pravděpodobně bude vyžadovat další funkce. Zatím nemám připravený žádný hotový design a právě teď nemám nic k začlenění do DST.
28. říjen, originál
Tento patch opravuje to, co, jak doufám, jsou nesprávné předpoklady o vrstvě DMA enginu. Nejenom že hardware od Intelu(r) umí DMA, ale DMA se dá použít i pro jiné věci než memcpy a snižování zátěže RAIDu (RAID offloading), popsal Haavard Skinnemoen svůj malý patch k popisu volby DMADEVICES v Kconfig. Dodal: Nechápejte mě špatně; myslím si, že si Intel zaslouží hodně respektu za vytvoření tohoto frameworku. Nicméně, to je také důvod, proč jsem byl trochu zklamán, když jsem zjistil, že se zdá být poněkud méně obecný, než jsem původně doufal.
DMA řadiče, které mohou podporovat čistou akceleraci memcpy dodatečně k tradičnějším slave DMA, jsou velmi běžné v SoC (system on chip, systém na čipu) zařízeních a já si myslím, že Linux pro to potřebuje společný framework. Existující DMA engine framework se tomu zdá být docela blízký, ale myslím si, že potřebuje víc vstupů z toho davu embedded zařízení předtím, než bude zcela použitelný pro velké množství embedded systémů.
29. říjen, originál
Jeff Garzik zaslal sérii dvou patchů zavádějící infrastrukturu upozorňující na asynchronní události [asynchronous event notification infrastructure], která zpřístupňuje SATA asynchronní upozorňování [asynchronous notification, AN] pro CD/DVD zařízení, která je podporují.
U zařízení, která podporují SATA AN (což umí jenom ta nejnovější), to znamená, že HAL a další uživatelské utility se nepotřebují opakovaně dotazovat CD/DVD zařízení, aby zjistily, jestli uživatel nevyměnil nosič.
První patch je pro ovladač SCSI. Je založen na práci Kristena Carlsona Accardiho, společně s pořádnou pomocí od Jamese Bottomleyho. Druhý patch aktualizuje libata, aby mohla použít novou infrastrukturu SCSI událostí.
30. říjen, originál
Víceúčelový vstup/výstup [General Purpose Input/Output, GPIO] je flexibilní softwarem řízený digitální signál. Tyto signály poskytuje mnoho druhů čipů a znají je vývojáři Linuxu, kteří pracují s embedded a zakázkovým hardwarem, začíná Documentation/gpio.txt.
K nedávné sérii čtyř patchů David Brownell poznamenal: Když jsme minulý rok sepsali Documentation/gpio.txt - Programovací rozhraní GPIO, objevilo se tam několik vlastností v kategorii "tohle bychom časem chtěli, ale prozatím bez toho budeme živi". V tomto postu následuje několik patchů, které některé z těchto vlastností přidávají. Potom pokračoval popisem dvou nových vlastností zavedených, které patch přidává:
1) Implementace frameworku v lib/gpiolib.c... rozhraní poskytované uživatelům GPIO se nemění, ale poskytovatelé se nyní mohou připojit [hook up] přes "gpio_chip", který umožňuje koexistenci několika typů poskytovatelů GPIO. Příklady: SoC-nativní GPIO, jaká poskytují FPGA, I2C, SPI GPIO expandery atd.
2) I2C ovladač pro GPIO expandery pcf8574/8575... Na embedded hardwaru jsou vcelku běžné a v externích stromech je obvyklé mít ošklivé, pro jednotlivé desky specifické hacky, které dané GPIO zpřístupňují ovladačům. Myslím si, že na rozdíl od takových hacků by použití standardních GPIO volání mělo být začlenitelné do upstreamu.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Minimálně myslím, že takhle třeba nebudu moci mít root partition na ntfs ne - coz je problem i pro ZFS?S pomocou initrd mozes (pokial tam nie su ine problemy), podobne ako root na iSCSI (tam je zase treba userspace daemon), proste sa to zabali do initrd
A taky bych si tipl, že Ingo nekecá, ale nemá pravdu, ale v originálo mohlo být ledascos.V originále je "kidding" (u každého článku je odkaz)