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.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Následující obsah je © KernelTrap.
14. leden, originál
Díky použití techniky, která se nazývá metaclusterování [metaclustering], zrychlí tento patch významně e2fsck na ext3, prohlásil Abhishek Rai. Toto své tvrzení podložil údaji uvedenými ve starším vlákně: Patch u ext3 snižuje celkový čas fsck. Na téměř plném souborovém systému jsem pozoroval 50 - 65% zkrácení. Po několika optimalizacích fsck je to dokonce 80 %.
Většina kritiky se doteď zabývala hlavně problémy s formátováním, které bránily jednoduchému testování patche. Vyřešeno to bylo v novějších verzích. Objevila se také varování, že patch ovlivňuje velké množství ext3 kódu, a tudíž bude vyžadovat velmi důkladné testování.
Abishek popsal, jak patch dosáhne tak velkého navýšení výkonu: Metaclusterování se týká ukládání nepřímých bloků [indirect blocks] ve shlucích založených na skupinách místo toho, aby tyto bloky byly rozprostřeny společně s datovými bloky. Díky tomu je e2fsck rychlejší, protože může číst a ověřovat nepřímé bloky bez nadbytečného pohybu hlaviček disku. Na druhou stranu, pokud se to udělá bez rozmyslu, může být negativně ovlivněna výkonnost při I/O operacích, takže jsme vložili nějaké optimalizace, aby taková sitace nenastala.
Nárůst výkonu fsck je tedy nakonec znát jenom v případě, kdy by čtení nepřímých bloků bylo úzkým hrdlem, což je vcelku často u středních a velkých disků, na kterých je mnoho dat. Pokud čtení nepřímých bloků úzkým hrdlem není, e2fsck je obvykle vcelku rychlý i tak, takže zlepšování výkonnosti není nutné.
Takové malé varování: Linux vypadá jako unix, ale implementoval jsem ho od základů a téměř bez literatury o tom, jak se to "má dělat".
Linus Torvalds, zpráva z 12. ledna 1992 na Linux Activists mailing list.
14. leden, originál
Text níže je hlavně pro nováčky - rozepisuji se v něm podrobněji na téma "jak podle hlášení o chybě najít zdroj chyby," začal Al Viro kompletní rozbor dalšího oops linuxového jádra ve snaze naučit víc lidí, jak se to dělá. Al v návodu zahrnul i patch, který opravuje chybu, která oops způsobila. Poznamenal k tomu:
Takové rozbory by možná stály za to, abychom je dělali více či méně pravidelně, obzvlášť pokud se připojí více lidí. Nejde samozřejmě jenom o dohledávání oopsů jako takové, ale o to, že každý na to má svoje triky a shrnout je dohromady by mohlo mnoha lidem pomoci. Arjanova stránka nám dává hezkou sbírku oopsů, takže zjevně máme kde začít.
Spousta věcí je možná - alespoň v tom smyslu, v jakém NASA může říct "s dost velkou tryskou poletí všechno". Jestli je to k něčemu a vyplatí se to, to už jsou samozřejmě odlišné otázky!
Theodore Ts'o, zpráva z 12. ledna 2008 na Linux Filesystem Development mailing list.
16. leden, originál
Nesnáším vydávání tolika -rc, ale ještě víc nesnáším vydávání jádra, když mám pocit, že ještě není dovařené. Změny od -rc7 jsou přitom větší, než byly změny mezi -rc6 a -rc7 (pravděpodobně částečně proto, že lidé byli mezi -rc6 a -rc7 stále na dovolené, takže nám něco posílali až poté.) Takto Linus Torvalds zahájil vysvětlení, proč vydává ještě jeden release candidate místo konečného jádra 2.6.24.
Zkrátka, změny nejsou ve skutečnosti nijak velké a zkrácený log je vcelku nudný, takže jsem si docela jistý, že tohle je poslední -rc a konečné 2.6.24 bude pravděpodobně vydáno někdy příští víkend nebo tak. Mezitím to ještě otestujme a podívejme se, jestli dokážeme opravit nějaké poslední regrese.
Linus pokračoval shrnutím změn: Ovladače, síťování, nějaké aktualizace architektur a ACPI. Slušné množství opravdu malých začlenění. Upřímně nemůžu říct nic víc, než je v přiloženém logu - kromě "spousta malých nudných oprav" v tom není žádný spojující motiv. Tak to má být.
Myslím si, že nic z toho, o čem v tomto vlákně diskutujeme, se do 2.6.24 nechystá (pokud Linus nechce, aby jádro 2.6.24 přinesl velikonoční zajíček.)
Adrian Bunk, zpráva ze 14. ledna 2008 na Linux Kernel mailing list
17. leden, originál
Chris Mason oznámil verzi 0.10 svého nového souborového systému Btrfs, která obsahuje následující nové vlastnosti: explicitní zpětné odkazy [explicit back references], změna velikosti za běhu (včetně zmenšení), konverze z ext3 na btrfs na místě, podpora pro data=ordered, volby pro mount, které zakazují kopírování při zápisu [copy-on-write] a počítání kontrolních součtů, a podporu pro hranice [barrier] pro sata a IDE disky.
Formát disku se změnil, takže verze 0.10 není kompatibilní s verzí 0.9. Co se týče podpory pro zpětné odkazy, Chris napsal: Jádrem tohoto vydání jsou explicitní zpětné odkazy pro všechny bloky metadat, datové oblasti a položky v adresáři. Ty budou kritickým stavebním prvkem pro budoucí vlastnosti jako je fsck za běhu a migrace mezi zařízeními. Zpětné odkazy jsou ověřovány během mazání, zpětné odkazy na rozsahy jsou kontrolovány existujícím offline fsck.
Nakonec Chris uvedl několik detailů o utilitě pro konverzi z Ext3 na Btrfs: Konverzní program používá přirozenou vlastnost Btrfs - kopírování při zápisu - aby zachoval původní Ext3 souborový systém, přičemž sdílí datové bloky mezi Btrfs a Ext3 metadaty. Btrfs metadata se vytváří ve volném místě Ext3 a tuto změnu je možné provést natrvalo (místo, které využíval Ext3, je uvolněno) nebo se vrátit k původnímu Ext3.
Když jde o integritu dat, nemůžete hrát v kostky.
Rik van Riel, zpráva z 9. ledna 2008 na Linux Kernel mailing list
17. leden, originál
"Const" nikdy neznamenalo nic o tom, že se ta věc nebude měnit. Na tuhle pitomost zapomeňte. C nic takového nemá, začal Linus Torvalds odpověď na dotaz, proč je parametrem kfree() const ukazatel, "const" se týká typu ukazatele a slouží k tomu, aby se chybná užití zviditelnila během překladu. Nemá žádný další význam a kdokoliv si to myslí, toho čekají problémy.
K tomu nabídl dvě vysvětlení a začal velmi jednoduchou C sémantikou: Z velmi zjevné a velmi skutečné perspektivy volajícího, free()
skutečně nemění tu věc, na kterou ukazatel ukazuje. Dělá něco úplně jiného - zneplatní ukazatel jako takový. K tomu přidal druhý důvod: Všechno, co může brát jako parametr const ukazatel, by to mělo vždycky udělat. Proč? Protože chceme, aby typy byly tak těsné, jak je to jen možné, a běžný kód by měl potřebovat tak málo přetypování, jak je to jen možné. Když někdo poukázal na to, že GCC 4.2 vypisuje varování, když přetypovává const ukazatel na non-const, Linus odpověděl:
Buď nepoužívejte vadný překladač (přetypování const ukazatele na non-const rozhodně není chyba) nebo přetypujte na "unsigned long" (pokud si překladač i tak bude stěžovat, pak není jenom blbý, ale je vadný). Celý důvod správy paměti je v tom, že my víme, jak ukazatele fungují a chápeme, že mají bitovou reprezentaci, nejenom C sémantiku.
Jsem moc rád, že nemáš na práci nic jiného, než dělat trolla v diskuzích. Kdybys opravdu něco naprogramoval, měl bych strach, že se to dostane do něčeho, co lidé používají.
Alan Cox, zpráva ze 16. ledna 2008 na Linux Kernel mailing list
18. leden, originál
Pomalé servery, vynechávající zvuk, trhané video - všichni známe symptomy zpoždění (latence). Nicméně vědět, co se v systému skutečně děje, co latenci způsobuje a jak to opravit, to jsou složité otázky, na které momentálně není odpověď, píše Arjan van de Van v oznámení o vydání LatencyTopu, nástroje pro vývojáře, který zobrazuje systémová zpoždění, verze 0.1.
LatencyTOP je linuxový nástroj pro vývojáře softwaru (jak kernelu, tak userspace) zaměřený na identifikaci toho, kde se v systému objevují latence a který druh operace/akce způsobuje, že se latence objeví. Když je toto identifikováno, vývojáři mohou kód změnit tak, aby se nejhorším latencím vyhnuli.
Je mnoho typů a příčin latencí, LatencyTOP se specializuje na ty, které způsobují vynechávání zvuku a zadrhávání desktopů. Přesněji řečeno, zaměřuje se na případy, kdy program chce běžet a vykonávat užitečný kód, ale nějaký zdroj není k dispozici (a jádro proces zablokuje). Sledování probíhá jak na úrovni systému, tak na úrovni procesů, takže můžete vidět, co se v systému děje a který proces trpí zpožděním a/nebo ho způsobuje.
Slovní spojení "příliš malý" a "příliš nevýznamný" v mém slovníku vlastností patchů neexistují - z definice nejlepší patche jsou velmi malé a velmi nevýznamné (protože se nakonec zjistí, že o 1000 kroků dál dělají něco hustýho ;-). 99 % našich problémů vychází z patchů "příliš velkých" a "příliš viditelných".
Ingo Molnár, zpráva z 18. ledna 2008 na Linux Kernel mailing list
21. leden, originál
Jasně, já vím... další strom, to je to, co všichni chceme, zavtipkoval James Bottomley, když ohlašoval svůj nový strom kandidáti na začlenění [merge candidate], -mc.
Tento strom má specifický účel. Je to můj strom, který sleduje gitové a quiltové stromy všech ostatních, takže se mi dostane včasné varování, když by mělo dojít k nějakým problémům se začleňováním. Pak mě ale napadlo, že by mohl být užitečný také každému, kdo chce podrobněji sledovat, co se děje v upstreamu.
James dodal, že jeho strom je k dispozici v gitu a každou noc se automaticky překládá. Jak můžete vidět z odpatchování [revert] a přeskočení [skip], i teď máme problémy (a to je poté, co jsem opravil většinu z toho, co dělalo problémy u SCSI). Stromy ACPI a x86 odporně kolidují, takže jsem x86 vykopl. Jensův blokový strom obsahuje dva patche, které kolidují s Bartovým ide quiltem. Greg má ve svém stromu jeden patch, který koliduje s jedním z mých.
Tento strom se v součastnosti značně zaměřuje na ukládání dat (tj. například jsem nezačlenil síťové stromy a quilty, protože očekávám, že pravděpodobně nekolidují s mými SCSI stromy). Nicméně, pokud by se to více lidem hodilo, můžu zařadit i další.
Je až moc jednoduché něco jen tak zběžně prohlédnout, říct "vypadá to dobře" a pokračovat něčím dalším, že ano? Byl jsem zděšen, když jsem viděl seznam souhlasů (včetně mého) u commitu, který obsahoval problém s helper_unlock a který jsme právě opravili. Je vpravdě děsivé, že nikdo z nás se na to nepodíval dost zblízka, aby si toho všiml včas.
Nigel Cunningham, zpráva ze 17. ledna 2008 na Linux Kernel mailing list
22. leden, originál
Dokončení 2.6.24 se nyní očekává každým dnem, takže správci různých subsystémů začli připravovat shrnutí změn, u kterých se očekává, že budou začleněny do hlavní řady jádra během začleňovacího okna 2.6.25. Ingo Molnár mluvil o změnách pro architekturu x86: V x86.git je právě 763 commitů od více než 90 přispěvatelů, takže by v tomto mailu bylo obtížné všechny zmínit a poděkovat každému.
Společně s douhým seznamem dalších změn jmenoval: pokračující a intenzivní sjednocování arch/x86 a začištovací práce spousty lidí, FIFO frontu pro spinlocky pro zlepšení škálovatelnosti; "regset" generalizace - nejdůležitější krok směrem k podpoře utrace (== ptrace nové generace); podpora pro více než 255 CPU (až 4096, teoreticky až 65535); téměř kompletní podpora pro 64bitový paravirtualizovaný systém; podpora KGDB na x86, konečně!
Skláním se před tebou. Myslel jsem, že jsem udělal některé poněkud hrůzostrašné věci se zabudovanými funkcemi gcc a makry, ale od nynějška předávám svou korunu tobě. Jak by řekla moje dcera: tenhle patch spadl z ošklivého stromu a cestou dolů zasáhl každou větev. Velice impozantní.
Linus Torvalds, zpráva z 21. ledna 2008 na Linux Kernel mailing list
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
...než dělat trolla v disuzích...K teme:
Typo:Dík, opraveno.
Jestli to s těmi const Linus myslí vážně, tak mám pocit, že zešílel. Protože const slouží k označení konstatní věci.Pokud vím, tak specifikace jazyka C tvrdí něco jiného.
short s; void *v; s = (int)v & 0xffff;
Any pointer type may be converted to an integer type. Except as previously specified, the result is implementation-defined. If the result cannot be represented in the integer type, the behavior is undefined. The result need not be in the range of values of any integer type.
Mě se ten kód zkompiluje,No, gcc to vezme, ale g++ ne:
error: cast from 'void*' to 'int' loses precision
A pointer can be explicitly converted to any integral type large enough to hold it. The mapping function is implementation-defined [Note: it is intended to be unsurprising to those who know the addressing structure of the underlying machine. ]
Nevím, co je na přetypování nedefinovaného - chová se jasně.
Určitě? A jak?