Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Do konference přišlo celkem 3599 emailů, nejvíce jich poslali William Lee Irwin III, Alan Cox a Sam Ravnborg.
17. črc - 6. srp
Patrick Mochel napsal:
Přibližně před rokem mě naštvalo, jak se vyvíjely mé snahy o začlenění několika oprav, které jsem provedl v kódu swsusp (suspend-to-disk). Důvodů bylo více, ale v této chvíli jsou z většiny irelevantní. Pokusil jsem se celou věc urychlit rozdělením kódu, pojmenoval jsem novou větev pmdisk a začlenil jsem opravy. Měl jsem v úmyslu to opět spojit, ale okolnosti byly proti a mně nezůstal žádný čas, ve kterém bych se tomu mohl věnovat. Výsledkem byl stav, který celkovému úsilí škodil.
Rozdělení kódu bylo špatným rozhodnutím. Pavlovi se omlouvám, že jsem ho přehlížel, uživatelům se omlouvám, že zůstali s nevyvíjenou implementací uspání na disk.
Podařilo se mi vyšetřit trochu času a připravil jsem sadu patchů, které obě implementace spojí. Lze je aplikovat na čerstvý Linusův BK strom. Nezmizely žádné funkce a celkový přínos by měl být vyšší než u obou implementací zvlášť.
Patche odstraňují pmdisk z jádra a pročistí kód swsusp. Výsledkem je jediný, velmi vylepšený kód, který snad ostatním umožní, aby mu lépe porozuměli.
Kód swsusp byl připojen ke zbytku kódu Power Managment. Odstraňuje se tak nějaký duplicitní kód a hlavní vstupní body to trochu zjednoduší. Hlavní výhodou je to, že swsusp už nezávisí na /proc/acpi/sleep nebo na přítomnosti upraveného systémového volání sys_reboot(). Lze to využít zápisem do /sys/power/state. Další velkou výhodou je to, že můžeme v rámci platformy využít skutečné režimy s nízkým napájením (např. režim ACPI S4), místo abychom stroj pokaždé vypínali.
Provedl jsem pouze minimum testů, protože už jsem doslova venku ze dveří a na cestě do Ottawy, ale ověřil jsem, že to funguje alespoň na jednom laptopu s Pentiem-M (Compaq Evo N620c). Neměl jsem příležitost portovat nízkoúrovňové změny na architekturu x86-64. Mám to v TODO, stejně jako napsání formálního vysvětlení technických změn pro Documentation/
Uraženou diskuzi, ve které Patrick oznámil rozdělení kódu, najdete v Jaderných novinách 231.
V odpovědi na předešlou zprávu Pavel Machek Patrickovi poděkoval a začal zkoumat jeho patche. Nigel Cunningham, který měl připraveno množství vlastních patchů, řekl, že před posíláním svých patchů počká, dokud nebude spojení dokončeno. Andrew Morton poznamenal:
Prostě Patrickovo BK URL přidám do svého seznamu BK stromů, které jsou zařazovány do -mm. Nebudete mi to věřit, ale to znamená, že už mám 25 externích stromů.
Patricku, cokoliv přidáš bude automaticky nataženo do -mm, takže máš-li jinou adresu, kterou bych měl používat, dej mi vědět.
Pavel, Patrick a další pokračovali v práci na kódu už v přátelském duchu.
20. črc - 9. srp
Marcelo Tosatti napsal:
Vytvořil jsem adresář pro ukládání dosud nevyřešených problémů v 2.4: http://master. kernel.org/~marcelo/pending-2.4-issues/
Soubor INDEX:
Toto je seznam známých nevyřešených problémů s 2.4. Každý soubor
představuje jednu záležitost. Ano, mohlo by to být vylepšeno, ale právě
teď je to KISS [Keep It Simple, Stupid = Nekomplikuj to, troubo].
Zwane Mwaikambo navrhl vyhledávat chyby v bugzilla.kernel.org. Marcelo mu poděkoval a začal s tím.
21. črc - 7. srp
James Morris napsal: Tento patch odstraňuje cryptoloop, které je prolezlé chybami, nikdo jej nespravuje a údajně má několik bezpečnostních slabin. Odstraněním cryptoloop by se zároveň mělo dostat více testování dm-crypt. Andrew Morton odpověděl: OK - pokud si nikdo nebude dostatečně přesvědčivě stěžovat, vypustíme cryptoloop z 2.6.9.
Dale Fountain reagoval: Cryptoloop je zastaralé, ale to neznamená, že by mělo být vymazáno. Stejně jako jiná zastaralá API, která dlouho zůstávají součástí (do další velké verze), aby měli lidi možnost změnit své nástroje. Nikdo jiný cryptoloop nepoužívá? To opravdu stačí pět malých verzí (zatím asi 5 měsíců)? Navrhl: Lepší by bylo se cryptoloop kompletně zbavit v 2.7, až bude dm-crypt dostatečně vyspělé. James odpověděl:
Jedním z důvodů pro odstranění cryptoloop je snaha pomoci dm-cryptu rychleji vyspět.
Z několika emailů, které jsem dostal soukromě, to vypadá, že dm-crypt má problémy s bezpečností a je potřeba na tom pracovat. Musíme dát dohromady bezpečnost více než cokoliv jiného.
Vypusťme tedy technicky horší z těch dvou (cryptoloop) a koncentrujme se na vyspravení toho druhého (dm-crypt).
Andrew také poznamenal: Největší starost mi dělá tvrzení, že cryptoloop není dostatečně bezpečný. Je-li to pravda, bylo by lepší to dát úplně pryč - místo abychom uživatele nechali v domnění, že jejich data jsou v bezpečí.
V jednu chvíli Andrew řekl, že by rád slyšel od někoho, komu by odstranění cryptoloop ztížilo práci; a Walter Hofmann napsal:
Já cryptoloop používám a byl bych dost otrávený, kdyby ze stabilní série zmizelo. Kromě toho jsem v jiném mailu v této diskuzi četl, že dm-crypt nefunguje se souborovým ukládáním (cryptoloop používám na souboru), a že je nové a může mít chyby.
Opravdu mě překvapuje argumentace lidí, kteří tvrdí, že dm-crypt není dostatečně testovaný, takže cryptoloop musí vypadnout, aby to lidi donutilo dm-crypt testovat na svých cenných datech. To je postavené na hlavu. Nejprve musí být dm-crypt stabilní, bezpečné a plně vybavené funkcemi, pak mohou lidi svá data do dm-crypt převést a až teprve potom může být cryptoloop odstraněn.
Pár lidí nabídlo rady ohledně migrace na dm-crypt, zatímco jiní potvrdili, že jsou na tom stejně jako Walter, a neradi by se dočkali odstranění cryptoloop bez jasné alternativy.
11. srp - 16. srp
Jeff Garzik napsal:
Coby autor současného linuxového SATA ovladače dostávám hlavním nápor otázek a zpráv o "chybách" typu "Linux nepodporuje můj hardwarový SATA RAID". Ach jo. Pitomá marketingová oddělení.
Takže jsem dal dohromady FAQ. Nepřipomíná vám to něco...?
Willy Tarreau odpověděl: Líbí se mi to. Docela jednoduché. Vždycky žasnu, kolik lidí skutečně věří, že tyhle karty doopravdy poskytují hardwarový RAID. Problém je, když řeknete prodejci, že chcete do kupovaného systému přidat hardwarovou RAID kartu a nakonec skončíte s laciným Silicon Image... Jednou se nám to stalo a vůbec legrační to není.
14. srp - 15. srp
Andres Salomon napsal:
Někde v rámci série 2.6 došlo ke změně, která způsobuje, že distclean automaticky vymaže podadresář debian/ z vrchního adresáře stromu jádra. To je nepříjemné pro oficiální balíčky Debianu; v balíčcích by adresář debian neměl být vymazán. Aplikujte, prosím, připojený patch. Zařídí, aby byl adresář debian/ vymazán pouze pokud neexistuje debian/official.
Sam Ravnborg odpověděl:
Takové výjimky nejsou přijatelné.
Způsobuje-li to problémy, jsou dvě možnosti:
1) Přejmenovat adresář v Debianu nebo v jádře.
2) Debian opatchuje kernel.
Dával bych přednost 1).
Andres odpověděl: Tohle není výjimka; Debian ten adresář používá už roky a kernel se najednou rozhodl nejen použít stejný adresář, ale i si jej přivlastnit a vymazat při distclean. Tím, že poskytujete parametr pro vytváření balíčku pro Debian, se vám podařilo přidělat práci těm, kteří ve skutečnosti vytvářejí a spravují systém, na kterém vaše balíčky běží. Zvaž to, prosím. A navrhl doplnit Samův seznam o třetí možnost:
Což takhle ten adresář nemazat, když jste ho nevytvořili? Debian už takhle patchuje jádro, ale změny/opravy posíláme Linusovi a spol. A tohle je jedna z oprav, které by v hlavním jádře být měly. Budete-li poskytovat make parametr pro *Debian*, ponechte ho v souladu se standardy Debianu. Proč se jinak obtěžovat? Debian má své vlastní podporované způsoby vytváření balíčků kernelu (pojmenované, kupodivu, kernel-package).
Upřímně bych byl radši, kdyby byl ten parametr pro make úplně odstraněn. Debian a distribuce na Debianu založené poskytují své vlastní balíčky s jádrem. Uživatelé kompilující svůj vlastní kernel mají možnost využít Debianem podporovanou metodu (nebo také jen tak kopírovat zkompilované kernely, aniž by se trápili s balíčky). Vytváření balíčku bez kernel-package není podporované; postará se to v postinst vůbec o grub nebo lilo?
Sam řekl: Nechme jádro využívat adresář pojmenovaný 'deb', aby to dpovídalo tomu parametru deb-pkg. A Andres odpověděl: Tak je to fajn. Předpokládám, že úmyslem je používat $(SRCDIR)/deb/debian místo $(SRCDIR)/debian. Konec problému, konec vlákna.
V originálu Kernel Traffic 274 vyšla navíc ještě tato témata:
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: