Příspěvek na blogu Codean Labs rozebírá zranitelnost CVE-2024-4367 v PDF.js, tj. mj. prohlížeči PDF souborů ve Firefoxu. Při otevření útočníkem připraveného pdf souboru může být spuštěn libovolný kód v JavaScriptu. Vyřešeno ve Firefoxu 126.
Lazygit byl vydán ve verzi 0.42.0. Jedná se o TUI (Text User Interface) nadstavbu nad gitem.
K open source herní konzole Picopad přibyla (𝕏) vylepšená verze Picopad Pro s větším displejem, lepšími tlačítky a větší baterii. Na YouTube lze zhlédnout přednášku Picopad - open source herní konzole z LinuxDays 2023.
Byla vydána (𝕏) nová major verze 17 softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech GitLab (Wikipedie). Představení nových vlastností i s náhledy a videi v oficiálním oznámení.
Sovereign Tech Fund, tj. program financování otevřeného softwaru německým ministerstvem hospodářství a ochrany klimatu, podpoří vývoj FFmpeg částkou 157 580 eur. V listopadu loňského roku podpořil GNOME částkou 1 milion eur.
24. září 2024 budou zveřejněny zdrojové kódy přehrávače Winamp.
Google Chrome 125 byl prohlášen za stabilní. Nejnovější stabilní verze 125.0.6422.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 9 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Textový editor Neovim byl vydán ve verzi 0.10 (𝕏). Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Byla vydána nová verze 6.3 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.15.
Dnes ve 12:00 byla spuštěna první aukce domén .CZ. Zatím největší zájem je o dro.cz, kachnicka.cz, octavie.cz, uvycepu.cz a vnady.cz [𝕏].
3. bře - 19. bře
Pierre Ossman napsal:
Posílám patche přidávající podporu pro Secure Digital - mám je tu už chvíli. Snažil jsem se už dříve získat nějaké komentáře k možnosti začlenění, ale protože jsem nic nedostal, prostě to navrhuji k zařazení do 2.6. Původně to bylo oproti jádru 2.6.10, ale není problém s aplikací na 2.6.11 (jedna malá nepřesnost).
Přehled změn:
Patch je zpětně kompatibilní a k využití 4bitové sběrnice a načítání přepínače "pouze pro čtení" potřebuje pouze aktualizované ovladače (neopravené ovladače budou používat 1bitovou sběrnici a umožňovat zápis).
Možná se však spolu s tím ukážou nové chyby. S mými ovladači jsem odhalil, že velmi malé přenosy (< 16 bajtů) vždycky selžou. Je potřeba to testovat, ale já k hardwaru nemám přístup. MMC by mělo fungovat i nadále dobře, protože MMC je detekováno před SD.
Pavel Machek byl nadšený, že na této věci někdo pracuje. A Marcel Holtmann se zeptal: Nedávno jsem obdržel žádost o podporu Bluetooth SD karet. Ty používají SDIO a mám pocit, že jsou teď podporovány pouze paměťové karty. Plánuješ přidělat i podporu SDIO Pierre odpověděl: To bych musel mít hardware, na kterém bych si s tím musel hrát. Nechcete mě někdo zasponzorovat? Specifikace SDIO je veřejně dostupná na webu asociace SD karet, takže zvládnout základní podporu by nemělo být tak těžké. Ale dokud nebudu mít hardware, na kterém by to šlo testovat, moc toho neudělám. Možná bych potřeboval i specifikace té karty; zatím jsem se na SDIO moc nekoukal. Marcel napsal, že ten hardware také nemá a zeptal se, jestli se někdo nenajde - ale žádná odpověď nepřišla.
14. bře - 21. bře
Phillip Lougher napsal:
Prosím o začlenění následujících dvou patchů, které přidávají do jádra SquashFS. SquashFS je samostatný, komprimovaný filesystém, který je již několik let bez problémů používán velkým počtem projektů.
Dost lidí mě začalo žádat o to, abych to poslal k posouzení. Zvažte, prosím, začlenění.
Andrew Morton a další přišli s trochou kritiky patche a na jiném místě řekl Pavel Machek: Takže nahrazujeme výrazně omezený CramFS také omezeným SquashFS... Pro živá DVD je 4GB omezení filesystému určitě dost nepříjemné a 4GB limit velikosti souboru se také nebude líbit. Šlo by tyhle věci opravit? Phillip měl pocit, že není fér srovnávat SquashFS a CramFS: SquashFS je o hodně lepší než CramFS. Hlavním cílem SquashFS bylo dosáhnout nejvyšší komprimace (samozřejmě s použitím zlib) mezi všemi linuxovými souborovými systémy - což se podařilo, a ještě k tomu je i nejrychlejší. Překonání hranice 4GB bylo také cílem, ale až druhotným. Pro většinu nasazení je komprimovaných 4GB (to dělá nekomprimovaných 8GB nebo více dat) OK. Ohledně 4GB omezení ještě Phillip řekl: Doufám, že podporu pro více než 4GB dodělám letos. Záleží to na tom, kolik budu mít volného času.
Pavel souhlasil, že SquashFS je výrazně lepší než CramFS, a omluvil se za srovnávání. Ale připojil: Mít v jádře dva různé komprimované filesystémy se mi nezdá moc dobré. Uznal také, že (nekomprimovaných) 8GB je užitečných, ale přesto řekl, že by byl nejraději, kdyby žádný limit neexistoval. Willy Tarreau poznamenal:
SquashFS je *vynikající* filesystém s velmi vysokým komprimačním poměrem a velkou rychlostí na pomalých I/O zařízeních, jako jsou třeba CD. Používám ho k ukládání root FS v initrd a upřímně, mít plně funkční systém v obraze malém 7MB je dostatečné zlepšení oproti CramFS.
Pokud časem zmizí limit 4GB, doufám, že to nebude na úkor velikosti obrazu, protože to by byl krok zpátky. Možná by to mohla být jiná verze s jiným formátem (např. SquashFS v3), stejně jako jsme měli ext a pak ext2 nebo jffs a jffs2 atd...
Phillip poukázal na to, že není důvod vybírat pro oficiální jádro jen jeden komprimovaný souborový systém, protože nekomprimovaných je také spousta a nikdo nějak vážně nenavrhuje, že by se měl vybrat jen jeden. A také připomněl, že v jádře už teď jsou tři komprimované filesystémy: JFFS2, zisoFS a CramFS - nikdo si nestěžoval, když byly přijaty, tak proč si stěžovat na SquashFS?
A dodal: Žádám o začlenění _teď_, protože uživatelé mě o to žádají _teď_. Pokud se do jádra nedostane, budou chtít vědět, proč se jaderná klika stala netečnou k novým projektům, které považují za klíčovou součást svého linuxového "prožitku". A já to budu chtít vědět taky. Pavel odpověděl: Dávat to do jádra, protože to chtějí uživatelé, to... není dobrý důvod. Měl bys to tam dát, pokud by bylo správné, aby to tam bylo.
Phillipovi došla trpělivost a vypěnil. Josh Boyer se za něj postavil a napsal: Jde o užitečný, stabilní a spravovaný filesystém, takže jsem trochu překvapený, že je tu proti začlenění tolik odporu. V tuto chvíli se do toho vložil Andrew Morton:
Ačkoliv jsem to sledoval jen jedním okem, nepřipadá mi, že by tu bylo příliš odporu. Jde o to, že navrhovatelé SquashFS jsou tázáni na důvody, proč jádro tento souborový systém potřebuje. Tomu nebylo věnováno při úvodním odeslání patche žádné úsilí (z toho plyne poučení).
Chápu-li to správně, tak nejvýznamnějším problémem je limit 4GB a zdá se, že odpovědí je "jde o FS pro embedded systémy a 4GB je už takhle šíleně moc". Je-li to skutečně tak, řekněte to a my to jako argument posoudíme.
Neměli bychom z vás takové důležité informace tahat jako na mučidlech. Vy jste experti na SquashFS. Tak nám o něm povězte.
17. bře - 19. bře
Během debuggování problémů s bránou BitKeeper->CVS zmínil Larry McVoy:
Podívejte se na tohle: http://www.bitkeeper.com/press/2005-03-17.html. Je to velmi prostý open source BK klient. Neumí nic moc kromě sledování stromu, ale dělá to dobře. A umí ještě něco: všechny začleňovací komentáře dává do BK/ChangeLog, takže je nemusíte stahovat po drátě.
Je určen těm, kteří jen chtějí nejnovější a nejlepší snapshot a vědí, jak používat cp -rp a diff -Nur. Není to náhrada za CVS bránu, ale funguje na všechny stromy na bkbits.net. Jen aby nedošlo k nedorozumění: nerušíme CVS bránu, tohle je "navíc", ne "místo".
Zmínil také, že pro kód bude vybrána BSD licence. Erik Andersen odpověděl: Díky! Je fajn mít konečně open source nástroj ke stahování přímo z BK. Zatím to funguje výborně; jak stahování stromů, tak jejich aktualizace při aplikování patchů. Larry ještě řekl:
Je to open source. Doufám, že jej lidi vezmou a udělají z toho, cokoliv potřebují. Jsme ochotni přispět, jak budeme moci, budou-li pro nové funkce potřeba změny protokolu. Berte to jako prototyp. Opravdu jednoduchý - lze snadno upravit.
Pokud chcete, abychom vaše změny distribuovali, pošlete patch. Jestli ne, taky fajn. Můžete to vzít a udělat z toho, cokoliv budete chtít. Pokud k tomu potřebujete jinou licenci, dejte mi vědět. Je mi to skutečně jedno, klidně dám ten kód do public domain.
20. bře
Magnus Damm napsal:
Tohle je sada patchů umožňujících automaticky generovat dokumentaci k parametrům, které lze jádru předat na příkazové řádce. Postup je jednoduchý - název, druh a popis parametru jsou uloženy v sekci nazvané __param_strings. Po sestavení vmlinux je tato sekce vytažena pomocí objcopy a skript vygeneruje primitivní - ale aktuální - dokument.
V současné době zůstává ta sekce v binárce jádra. Dokument není generovaný z Makefile, takže zvědavý uživatel musí provést:
$ objcopy -j __param_strings vmlinux -O binary foo
$ chmod a+x scripts/section2text.rb
$ cat foo | ./scripts/section2text.rb
Jo, a potřebujete nainstalované ruby, aby vám skript běžel.
Ten ruby skript (section2text.rb) zkontroluje, jestli je MODULE_PARM_DESC() použito bez module_param(). Uvidíte pár zajímavých překlepů.
V budoucnu bych to mohl rozšířit tak, aby se __setup(name) nahrazovalo __setup(name, descr). A dokumentaci by to chtělo ukládat někam, odkud by uživatel mohl snadno zobrazit vygenerovaný seznam parametrů přímo ze zavaděče systému.
V originálu Kernel Traffic 304 vyšla navíc ještě tato témata:
Tento článek vychází ze seriálu Kernel Traffic (www.kerneltraffic.org) a je zveřejněn pod licencí GPL verze 2.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
13.4.2005 15:09
Jiří Svoboda | skóre: 37
| blog: cat /dev/mind
| Prostějov
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
13.4.2005 13:48