Desktopové prostředí Budgie bylo vydáno ve verzi 10.10. Dokončena byla migrace z X11 na Wayland. Budgie 10 vstupuje do režimu údržby. Vývoj se přesouvá k Budgie 11. Dlouho se řešilo, v čem bude nové Budgie napsáno. Budgie 10 je postaveno nad GTK 3. Přemýšlelo se také nad přepsáním z GTK do EFL. Budgie 11 bude nakonec postaveno nad Qt 6.
OpenChaos.dev je 'samovolně se vyvíjející open source projekt' s nedefinovaným cílem. Každý týden mohou lidé hlasovat o návrzích (pull requestech), přičemž vítězný návrh se integruje do kódu projektu (repozitář na GitHubu). Hlasováním je možné změnit téměř vše, včetně tohoto pravidla. Hlasování končí vždy v neděli v 9:00 UTC.
Byl vydán Debian 13.3, tj. třetí opravná verze Debianu 13 s kódovým názvem Trixie a Debian 12.13, tj. třináctá opravná verze Debianu 12 s kódovým názvem Bookworm. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 a Debianu 12 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
Na stránkách Evropské komise, na portálu Podělte se o svůj názor, se lze do 3. února podělit o názor k iniciativě Evropské otevřené digitální ekosystémy řešící přístup EU k otevřenému softwaru.
Společnost Kagi stojící za stejnojmenným placeným vyhledávačem vydala (𝕏) alfa verzi linuxové verze (flatpak) svého proprietárního webového prohlížeče Orion.
Firma Bose se po tlaku uživatelů rozhodla, že otevře API svých chytrých reproduktorů SoundTouch, což umožní pokračovat v jejich používání i po plánovaném ukončení podpory v letošním roce. Pro ovládání také bude stále možné využívat oficiální aplikaci, ale už pouze lokálně bez cloudových služeb. Dokumentace API dostupná zde (soubor PDF).
Jiří Eischmann se v příspěvku na svém blogu rozepsal o open source AdGuard Home jako domácí ochraně nejen před reklamou. Adguard Home není plnohodnotným DNS resolverem, funguje jako DNS forwarder s možností filtrování. To znamená, že když přijme DNS dotaz, sám na něj neodpoví, ale přepošle ho na vybraný DNS server a odpovědi zpracovává a filtruje dle nastavených pravidel a následně posílá zpět klientům. Dá se tedy používat k blokování reklamy a škodlivých stránek a k rodičovské kontrole na úrovni DNS.
AI Claude Code od Anthropicu lépe rozumí frameworku Nette, tj. open source frameworku pro tvorbu webových aplikací v PHP. David Grudl napsal plugin Nette pro Claude Code.
Byla vydána prosincová aktualizace aneb nová verze 1.108 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.108 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Na lasvegaském veletrhu elektroniky CES byl předveden prototyp notebooku chlazeného pomocí plazmových aktuátorů (DBD). Ačkoliv se nejedná o první nápad svého druhu, nepochybně to je první ukázka praktického použití tohoto způsobu chlazení v běžné elektronice. Co činí plazmové chladící akční členy technologickou výzvou je především vysoká produkce jedovatého ozonu, tu se prý podařilo firmě YPlasma zredukovat dielektrickou
… více »Do konference přišlo celkem 3112 emailů, nejvíce jich poslali Alan Cox, Jens Axboe, William Lee Irwin III.
Linus Torvalds napsal:
Dobře, nejde to udělat elegantně, takže se o to nebudu ani pokoušet. Jdu usadit svou zadnici kvůli skutečně velmi impozantní plamenné diskusi a mé azbestové spodky jsou nasazeny a mimořádně nepohodlné.
Chci jasně říci, že Linux s DRM nemá vůbec problém.
Tak, řekl jsem to. Už jsem ze záchodu pryč. Takže začněte...
Už jsem o tom soukromě diskutoval s různými lidmi a zjistil jsem, že spousta lidí chce používat kernel tak, aby neumožňoval DRM. Ať už skrze politické rozhodnutí nebo rozšířením GPL.
Svým způsobem se diskuse podobají rok starým diskusím o softwarových patentech týkajících se GPL-NG: "nelíbí se nám to, takže raději nějak změňme licenci, aby to nešlo". A jako u problému se softwarovými patenty, osobně DRM nemám rád, ale nakonec se cítím stejně: Jsem "Oppenheimer" a odmítám hrát politické hry s Linuxem a myslím si, že můžete používat Linux pro co chcete - což rozhodně obsahuje i věci, které bych osobně neschválil.
GPL po vás požaduje zdroják od kernelu, ale neomezuje vás, co můžete s kernelem dělat. V podstatě je to další příklad toho, proč mě RMS [Richard M. Stallman] nazývá "jen inženýr" a myslí si, že nemám žádné ideály. (Osobně to cítím jako přednost - snaha vytvořit ze světa trochu lepší místo bez vnucování svých morálních hodnot ostatním. Dělejte si, co chcete, jsem jen inženýr, který chce udělat nejlepší možný operační systém.)
Krátce, je úplně v pořádku podepsat obraz kernelu, nepřímo to dělám již dnes, neboť kernel.org podepisuje tar balíčky, které tam nahraju, aby si lidé mohli ověřit, že přišly touto cestou. Udělat to samé na binárce, v tom není rozdíl: podepsání binárky je korektní způsob ukázání světu, že jste to vy, kdo za ní stojí a že vy jí věříte. A protože si dovedu představit sebe podepisujícího binárky, nemyslím, že bych v tom mohl někomu jinému bránit.
Další částí diskuse o DRM je fakt, že podepisování je jen prvním krokem: jednat na základě toho, zda je binárka podepsána či nikoliv (například odmítnutím spustit ji nebo dát ji tajný klíč) je také požadováno. Ale protože podpis je zbytečný, dokud jej pro něco nepoužíváte a protože rozhodnutí, jak používat podpis, jasně leží mimo dosah kernelu (a proto není odvozenou [derived] prací), musím přesvědčit sebe, že je nejen v pořádku jednat na základě znalosti, zda je kernel podepsaný či ne, ale že je to mimo rozsah toho, o čem GPL mluví a proto je irelevantní vůči licenci.
Tak a je to. Chtěl jsem to vynést ven, protože vím, že jsou zde lidé, kteří si myslí, že podepsané binárky jsou podvracením (či perverzí) GPL a chtěl jsem zajistit, že lidé nebudou žít v nepochopení, že to nejde udělat. Myslím, že je zde spousta dobrých důvodů, proč podepisovat (a verifikovat) obrazy jádra a přestože některé použití podpisů jsou hnusné, nevidím žádný čistý způsob, jak rozlišit dobré a špatné podepisovače [signers].
Komentáře? Rád bych viděl nějakou skutečnou diskusi ohledně tohoto problému, ale nakonec jsem osobně přesvědčen, že to musíme povolit.
Mimochodem, jedna věc, která jasně není povolena GPL, je skrývání soukromých klíčů v binárce. Můžete podepsat binárku jako výsledek build procesu, ale nemůžete vytvořit binárku, která si je vědoma určitých klíčů bez toho, aby ty klíče byly veřejné - protože tyto klíče by zřejmě musely být součástí kernelu samotného. Takže nepleťte tyto dvě věci dohromady: externí klíč aplikovaný na kernel (OK) a začlenění klíče do kernelu (také to jde, ale GPL požaduje, aby takový klíč byl zveřejněn jako "zdrojový kód").
Greg KH odpověděl, že zná spoustu lidí, kteří by takhle chtěli (a dělají to) používat Linux a že rád vidí tak explicitní tvrzení, že je to přijatelné. To vyjasní tenhle problém.
Andre Hedrick napsal delší dopis na podporu Linuse, ve kterém ukázal, že hardware již podporu DRM obsahuje a že se musíme smířit s tím, že DRM již zde je. Jediným řešením je ovládat jej, proto Andre s pomocí několik další členů komise NCITS T13 za pomoci Microsoftu zařídil, že konečný uživatel může tuto sadu vlastností vypnout.
Andre dále dodal, že digitální podepisování se dá použít pro ochranu embedded nebo distribučních prostředí. DRM je totiž obousečné a na to nemáme zapomenout. My jako Open Source komunita můžeme používat DRM jako prostředek pro povolení či odmítnutí funkčnosti. Nyní podle něj nastal čas, jak ovládat tento nástroj. Podobně jako u ohně, ovládněte DRM/CPRM a můžete z toho profitovat. Nechte mu volnost a shoříte.
Linus reagoval na obousečnost DRM:
Toto je nejdůležitější část pro zapamatování.
Bezpečnost je meč o dvou ostřích. Může být použita pro vás a může být použita proti vám.
Technologie samotná je vlastně neutrální a osobně jsem celkem optimistický, že zvláště v Open Source prostředí najdeme největší snahu používat bezpečnost ve prospěch zákazníka. Bezpečnost pro uživatele, ne pro utiskování uživatele.
Jinde William Lee Irwin III odpověděl Linusovi, že nemá zájem o řešení morálních problémů, ale zdá se mu, že DRM je jen transparentní komplot, jak zabránit bootování cizího kódu na různých strojích. Linus reagoval:
Buďme čestní - pro některé lidi to je přesný účel DRM. Žádné když, možná nebo ale.
Faktem je, že dokud vyrábíte hardware, můžete řídit, co na něm poběží.
GPL vyžaduje, abyste zpřístupnili software, ale nepožaduje, aby byl vyroben hardware tak, abys mohl vždy upgradovat. Můžete zapsat binárku kernelu do ROM a prodat ji se základní deskou. To je v pořádku a vždycky bylo. Dokud dáte k dispozici zdrojové kódu k softwaru, není zde nic, co by říkalo, že hardware musí být vytvořen tak, aby bylo snadné (či dokonce vůbec možné) změnit jeho binárku.
A jsou zde projekty pro "Open Hardware" (jako opencores.org atd.) a může se stát, že budou velmi důležité. Ale Linux je o Open Source, ale ne o hardware a hardwará otevřenost nikdy nebyla podmínkou pro běh Linuxu.
Roman Zippel hrdě ohlásil, že dokončil kompletně novou verzi ovladače souborového systému HFS+. Tuto práci umožnila firma Ardis Technologies. Ovladač je založen na originálním ovladači Brada Boyera ( http://sf.net/projects/linux-hfsplus).
Nový ovladač podporuje plný přístup pro čtení i zápis. Výkon
výrazně vzrostl, b-stromy jsou udržovány v keši stránek spolu s
hash tabulkou pro urychlení přístupu. Roman dále přidal podporu
hard linků. Fork zdrojů [resource fork] je dostupný skrze
<file>/rsrc.
Ovladač můžete stáhnout z http://www.ardistech.com/hfsplus/. README popisuje, jak ovladač zkompilovat..
Jeffrey Baker napsal, že jde o výrazný pokrok pro uživatele iPod a Maců, Miles Lane se kromě radostného výkřiku zeptal, kdy bude ovladač začleněn do jádra 2.4 či 2.5.
Brad Boyer napsal Romanovi, že
Roman odpověděl stručně:
Andi Kleen napsal:
Po intenzivní diskusi různých expertů v konferenci discuss@x86-64.org jsme zjistili, že správná adresa [vector] pro restartování 286+ CPU je f000:fff0, nikoliv ffff:0000. Oba se zdají fungovat na moderních systémech, nicméně první je správný.
Viz vlákna "DPMI on AMD64" a "Warm reboot for x86-64 linux" na adrese http://www.x86-64.org/mailing_lists/list?listname=discuss&listnum=0.
Jamie Lokier odpověděl:
Máš pravdu. To je, co 286 dělá, když přijme RESET signál.
Je to zajímavé, neboť jsem to byl já, kdo použil to ffff:0000 a to jsem se tehdy přečetl z knihy Phoenix BIOS book.
Právě jsem googloval a našel příklady dosovských programů používajících obě adresy.
Jos Hulzink dodal:
16-bajtový kód je příliš malý a obvykle obsahuje ten DLOUHÝ skok do užitečného adresového prostoru.
Když použijeme adresu f000:fff0, přežijeme BIOSy, které používají relativní skoky s negativními offsety nebo nepřímé krátké skoky.
Když je použita adresa ffff:0000 a kódový segment [CS] obsahuje jen 16 bajtů, nemůžete ani myslet na krátké skoky s negativními offsety. Kód v tak rané fázi totiž dostupný jen ke čtení, sebemodifikující kód (který používá absolutní adresy) může být také vyloučen.
Dobře, 386 a novější procesory potřebují daleký skok pro odemknutí A20-A31, takže myslím, že je bezpečné předpokládat, že všechny BOISy udělají daleký skok, jakmile to bude možné, což znamená, že je jedno, která adresa je použita.
Nicméně kvůli špatně se chovajícím BIOSům hlasuji pro adresu f000:fff0, dokud mi někdo neukáže papír, který říká, že je to špatné.
Do diskuse se pak zapojil i Linus Torvalds a vývojáři se trumfovali, kdo má pravdu.
Chien-Lung Wu se zeptal, zda Linux podporuje VRRP (Virtual Redundency Router protocol). Gianni Tedesco zaslal odkaz na Keepalived, and Maciej Soltysiak napsal:
Přečti si o vrrpd http://lartc.org/howto/lartc.other.html. Také vyzkoušej http://sourceforge.net/projects/svrrpd/.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz