Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).
Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.
Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.
Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.
Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.
Vyhledávač DuckDuckGo je podle webu DownDetector od 2:15 SELČ nedostupný. Opět fungovat začal na několik minut zhruba v 15:15. Další služby nesouvisející přímo s vyhledáváním, jako mapy a AI asistent jsou dostupné. Pro některé dotazy během výpadku stále funguje zobrazování například textu z Wikipedie.
Více než 600 aplikací postavených na PHP frameworku Laravel je zranitelných vůči vzdálenému spuštění libovolného kódu. Útočníci mohou zneužít veřejně uniklé konfigurační klíče APP_KEY (např. z GitHubu). Z více než 260 000 APP_KEY získaných z GitHubu bylo ověřeno, že přes 600 aplikací je zranitelných. Zhruba 63 % úniků pochází z .env souborů, které často obsahují i další citlivé údaje (např. přístupové údaje k databázím nebo cloudovým službám).
Open source modální textový editor Helix, inspirovaný editory Vim, Neovim či Kakoune, byl vydán ve verzi 25.07. Přehled novinek se záznamy terminálových sezení v asciinema v oznámení na webu. Detailně v CHANGELOGu na GitHubu.
Americký výrobce čipů Nvidia získal od vlády prezidenta Donalda Trumpa souhlas s prodejem svých pokročilých počítačových čipů používaných k vývoji umělé inteligence (AI) H20 do Číny. Prodej těchto čipů speciálně upravených pro čínský trh by tak mohl být brzy obnoven, uvedla firma na svém blogu. Americká vláda zakázala prodej v dubnu, v době eskalace obchodního sporu mezi oběma zeměmi. Tehdy to zdůvodnila obavami, že by čipy mohla využívat čínská armáda.
3D software Blender byl vydán ve verzi 4.5 s prodlouženou podporou. Podrobnosti v poznámkách k vydání. Videopředstavení na YouTube.
26.5.2009 06:43
Fluttershy, yay! | skóre: 93
| blog:
Další alternativou k data=ordered by mohl být režim data=guarded navržený Chrisem Masonem.
^_^
že zaznamen8v83 zpožděníAutor nebo překladatel měl problém s přepínáním klávesnice
A hned v další větě:
Z toho je zjjvný závěr,Další odstavec:
Tento režim odstraňuje potřebu zapisování datových bloků byly na disk před metadaty„Byly“ je tam zřejmě navíc.
Autor nebo překladatel měl problém s přepínáním klávesniceKorektor.
Z toho je zjjvný závěr,Tentokrát autor i korektor, já napsal zejvný
„Byly“ je tam zřejmě navíc.Robert asi tentokrát chvátal...
. Klobouk dolu před Jirkou - já už ani nevím, jak jsem to dělal, když jsem to ještě překládal sám...
Uživatelský slovník nemusí být jenom jeden. Můžete mít slovník pro každou aplikaci nebo obor nebo stupeň odbornosti zvlášť.
Chápu, že není dobré kdejaký jednoúčelový patvar přidat do slovníku. Ale pokud vám standardní slovník vyhodí 50 neznámých slov, z čehož jsou skutečné překlepy jen 3, tak je škoda nevyužít nástrojů, které máme. Až budete kontrolovat příští verzi, tak už vás těch 47 novotvarů obtěžovat nebude.
Já na gettextové překlady používám něco takového:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
27.5.2009 11:16
msgexec -i $< sed 'a\' | \
aspell --lang=cs --encoding=utf-8 list | \
aspell --lang=en --encoding=utf-8 list | \
sort -u >badtranslationlist
Myšlenka je vytáhnout z kódu obsahový text (ve vašem případě to budou textové uzly a hodnoty atributů alt a title; lze použít parametr aspellu --mode=html), který zkontrolujeme proti českému slovníku a zbytek proti anglickému. Výsledek setřepeme do seřazeného seznamu.
Takový seznam si pak pozorně přečteme a chybná slova v původním textu opravíme. Ustálené novotvary můžeme připadat do vlastního slovníku a ten pak použít při další kontrole. Tento postup opakujeme, dokud soubor badtranslationlist obsahuje slova, která se nám nelíbí.
Když se tak hromadně opravuje, tak bych přidal zajímavé slovo "zaznamen8v83".
Jinak super seriál, díky za překlady. Dnešní citát o samohláskách mě opravdu dostal.
Tak opravu beru zpět (už tu je), poděkování ne :)
fsync() nikdy nenarazil, zato s ním (nebo něčím, co se projevuje velmi podobně) už nějakou dobu válčím u XFS. Dokonce jsem už rezignoval a na velké filesystémy (stovky GB), na kterých hodlám mít image disků virtuálních strojů pro VMware, raději používám JFS.
Řekl bych, že ten problém se projevuje už nyní. Jakmile máte velkou diskovou cache, plnou nezapsaných dat a pak zavoláte fsync, tak data synchronizovaného souboru se umístí na konec fronty, ale de facto se vynutí vypláchnutí celé cache. A to je záležitost, která s dnešními obludně velkými paměťmi (a tedy i cachí) trvá znatelně dlouho.
Když jsem měl v počítači 32 MB RAM, tak disková cache zabírala několik megabajtů, disk byl schopen sekvenčního zápisu kolem 11 MB/s, takže (f)sync trval teoreticky nejdéle sekundu (u rozkouskovaného zápisu to mohlo být tak 5 sekund). To vzhledem k tehdejší rychlosti procesorů a častému swapování jste ani nepostřehl.
Dneska mám disk, který sekvenčně dá 50 MB/s, a v diskové cache třeba právě teď mám 153 MB. To už představuje teoretické minimální 3 sekundy. Tedy trojnásobné zhoršení.
Kdybych měl moderní stroj, tak mi disk dá 100 MB/s, ale pokud jej taky adekvátně zatížím (nějaké to desktopové prostředí, Firefox, Eclipse, Evolution, …), tak disková cache bude zabírat třeba gigabajt a vylití bude trvat alespoň 10 sekund.
Dneska mám disk, který sekvenčně dá 50 MB/s, a v diskové cache třeba právě teď mám 153 MB. To už představuje teoretické minimální 3 sekundy. Tedy trojnásobné zhoršení.
Kdyby šlo o tři sekundy, tak to neřeším. Problém, o kterém jsem se zmiňoval u XFS, se projevuje tak, že při 100 MB nezapsaných dat trvá provedení příkazu sync 30-60 sekund. Podobně třeba po vypnutí VMware virtuálního stroje následovala při troše smůly desítky sekund trvající prodleva, během které jeho UI nereagovalo a stejně tak všechno ostatní, co se snažilo přistupovat k disku (předpokládám, že VMware volá po vypnutí virtuálního stroje fsync() na image virtuálního disku). Mountováním s nobarrier se to zlepšilo, ale jen zhruba na polovinu, řešením byl teprve přechod na JFS.
To, co popisuji já, je problém blokové vrstvy. Vy jste měl spíš problém se souborovým systémem. Já XFS vůbec neznám, takže těžko můžu radit.
Tak mně napadá, jestli položka cached, kterou vypisuje free, je jen bloková cache nebo obsahuje i paměť alokovanou pro souborové systémy?
Kdyby to byla jen bloková cache (jak si myslím), tak co je v ní, už dávno prošlo (V)FS, takže její vylití by mělo být omezeno jen výkonností plánovače blokového I/O. Takže pokud ta cache neobsahuje hromadu drobných synchronních požadavků, které by mohly ucpat sběrnici z řadiče do disku režií ATA protokolu a donutit disk k neefektivnímu seekování, tak by měl jet disk na plno a cache by se měla vyprázdnit za pár sekund.
Tyhle potíže pozoruji, když mám CD-RW i pevný disk na stejném IDE kanálu, a cdrecord intentizvně komunikuje s CD mechanikou (třeba při záhájení nebo dokončení vypalování nebo při rychlém mazání TOC). Pak se nemám jak dostat k disku.
Tak mně napadá, jestli položka cached, kterou vypisuje free, je jen bloková cache nebo obsahuje i paměť alokovanou pro souborové systémy?
Tohle číslo je z tohoto pohledu celkem nezajímavé, protože to je veškerá disková cache, z níž většinu obvykle většinu tvoří data, která jsou načtena do cache, ale na disku jsou aktuální, takže je není potřeba zapisovat. Pro to, o čem se bavíme, je směrodatnější spíše hodnota Dirty v /proc/meminfo.
Tyhle potíže pozoruji, když mám CD-RW i pevný disk na stejném IDE kanálu, a cdrecord intentizvně komunikuje s CD mechanikou (třeba při záhájení nebo dokončení vypalování nebo při rychlém mazání TOC). Pak se nemám jak dostat k disku.
Tomu bych se samozřejmě nedivil, ale tohle není ten případ. Ty problémy jsem měl na počítači, kde disk i CD-RW mechanika byly na SATA řadiči (navíc na PCI-E sběrnici) a většinou se CD-RW mechanika vůbec nepoužívala. A nešlo jen o jeden počítač, u některých šlo dokonce o SCSI disk. Společným znakem byl 64-bitový procesor (tím ovšem nechci naznačovat, že na 32-bitových se to dít nemůže) a mám pocit, že s vícejádrovými procesory to bylo trochu výraznější (ale to nemám podloženo měřením).
Tiskni
Sdílej:
