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.
Wine 1.5.26 vyšlo 15. března s těmito změnami:
Wine 1.5.27 vyšlo 29. března s těmito změnami:
Lepší podpora zamykání souborů proti čtení/zápisu je něco, o čem se na LKML diskutovalo už před několika lety. Nyní se tento nápad vrátil a souběžně s tím se podpora této funkce řeší i ve Wine. A důvod? Tato funkce je používána především na Windows; na Linuxu sice historicky podpora pro zamykání souborů existuje, ale její užívání (a respektování) je naprosto volitelné. Přesněji řečeno: najít linuxovou aplikaci, která zamykání používá nebo alespoň respektuje, dá docela zabrat.
Kromě Linuxu se tento námět objevil i na mailing listu NetBSD.
Příznaky O_DENY* se od flock odlišují tím, že práce s nimi je atomická – o případném neúspěchu se tedy dozvíte už při otevírání souboru pomocí open() a uzamčení můžete rovněž provést už při otevírání. Zatím to ale vypadá, že i tak bude mechanismus O_DENY* nějakým způsobem volitelný (aplikace NEBO systémy nepoužívající příznak „chci respektovat zámky“ nebudou ovlivněny), protože uživatelé unixových systémů nejsou na tuto „šikanu“ z Windows navyklí a zvykat si nechtějí, proto ani nepřekvapí, že se podpora zamýšlí hlavně do síťovýcḧ systémů souborů CIFS a NFS.
Toť úvod. Jadernou část diskuze ponechme do případných Jaderných novin a podívejme se na debatu, která se odehrála na wine-devel. Pavel Shilovsky (mluvící o patchi pro Linux):
Tento patch přidává podporu příznaků O_DENY* do linuxové souborové vrstvy. Tyto příznaky mohou být používány libovolnou aplikací, která potřebuje používat řízení přístupu k souborům. VFS už podobnou schopnost má – nyní se to dělá přes mechanismus flock/LOCK_MAND, ale tento přístup není atomický. Tento patch přidává nové schopnost navrch existující podpory, ale nemění nic na voláních flock.
Příznaky mohou být používány v serverech NFS (vestavěných do jádra) a CIFS (Samba) a v aplikacích ve Wine skrze VFS (pro místní systémy souborů) nebo moduly CIFS/NFS. Toto pomůže například tehdy, kdy Samba a NFS server sdílejí ten samý adresář pro uživatele na Windows a na Linuxu nebo aplikace ve Wine používají sdílení Samba/NFS pro přístup ke stejným datům z různých klientů.
Vzhledem k předchozím diskuzím je nejpalčivější otázkou to, jak zabránit situacím jako DoS útokům, kdy např. /lib/liba.so může být otevřeno s příznakem DENYREAD nebo něčím takovým. To je důvod, proč je navíc přidán příznak O_DENYMAND. Nižším vrstvám se tak dává najevo, že aplikace chce používat vlastnosti příznaků O_DENY*. Zamezuje to dopadu na nativní linuxové aplikace (které O_DENYMAND nepoužívají) – takže tyto příznaky (a s tím spojená sémantika systémového volání open) jsou používány jen u aplikací, které to chtějí.
Takže tedy máme čtyři nové příznaky:
[...]
J. Bruce Fields se ozval s tím, že mu tento polovičatě mandatorní přístup nepřijde zrovna dobrý.
Mám tak trochu obavy: jde o mandatorní zámky a aplikace, které je používají, jsou zvyklé na to, že jsou správně vynucovány. Jsme si jistí, že aplikace, která otevře soubor s O_DENYWRITE nehavaruje, jakmile jí někdo bude pod rukama měnit data?
Obecně jsem z nápadu mít volitelně povinné zamykání nervózní. Raději bych viděl něco jako volbu pro mount, aby všichni věděli, že ostatní hrají na tomto systému souborů podle stejných pravidel, ale stále bychom měli možnost mít systémy souborů jako / bez této volby.
Zbytek diskuze se dále točil okolo volitelnosti těchto zámků. Zatím to vypadá, že se všichni (snad i včetně autora patche) přiklánějí k nové volbě pro mount.
Implementovat Direct3D navrch OpenGL je pracné. Dosahovat srovnatelného výkonu je ještě pracnější. Sám se o tom přesvědčuje Graham Knap, kterému vadí nižší výkon StarCraft II pod Wine:
Rád bych pomohl se zlepšením výkonu StarCraftu II pod Wine. Pracuji na tom s kamarádem. Během uplynulých týdnů jsme se snažili číst veškerou dokumentaci, co jsme našli. Různými způsoby jsme se to snažili profilovat, bez výrazného úspěchu.
Můj kamarád rozchodil WineD3D pod Windows. Sestavili jsme Wine z aktuálních zdrojáků, zkusili jsme to na dvou různých konfiguracích a máme podobné výsledky. [...]
Vypadá to, že WineD3D je příčinou většiny rozdílu ve výkonu. Windows se svým D3D nám dávají alespoň dvojnásobné FPS než Windows + WineD3D. Je tam i rozdíl mezi Windows + WineD3D a Linux + Wine, ale ten je mnohem menší, takže třeba něco jako 25 %.
Mohl by nám někdo poradit, jak najít nejvýznamnejší příčiny rozdílu ve výkonu? Nějaké tipy, jak to efektivně profilovat nebo trasovat?
Přispěchal Stefan Dösinger, který upozornil, že zlepšení výkonu není něco, co by se dalo vyřešit jen tak za víkend. Dále řekl, že je nutné rozlišovat mezi nedostatkem výkonu CPU a GPU. Pokud má změna rozlišení za následek výrazný rozdíl ve FPS, pak je problém zjevně v povelech pro GPU. Pokud zůstane výkon podobný, pak je zádrhel přímo na straně softwaru, kterému nestačí výkon CPU.
Graham za několik dnů přišel s informacemi, jak to vlastně je. A podle všeho výkon omezuje CPU:
Jak jsem uvedl v bugu Wine #24558, musím použít taskset, abych dostal vůbec nějaký rozumný výkon.
$ taskset -a -p 2 `pidof SC2.exe` $ taskset -p 1 `pidof SC2.exe`
Nejsem si jist, jestli to je vůbec chyba ve Wine. Řekl bych, že je to jen odlišnost v plánovači OS a správě výkonu. SC2 by asi mělo nastavit CPU affinity, ale neřekl bych, že to dělá.
Nastavení detailů grafiky a rozlišení obrazovky nemá na FPS velký vliv, takže si myslím, že nás omezuje CPU.
Na návrh zkusit omezit používaná CPU přímo ve Windows pak odpověděl:
To má rozhodně vliv. FPS během drobné nahrané bitvy:
Graham pokračoval výčtem způsobů, jak se snažili příčinu nedostatečného výkonu odhalit. Zkoušeli i nástroj perf, ten ale nedokázal ani při kompilaci s -ggdb pojmenovat symboly adresy v některých knihovnách Wine. Debata pak bohužel ustala.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
To je sice pravda, ale snadno se tomu zabrání. Počítám, že taky nebrojíte proti hláškám typu "opravdu chcete naformátovat tenhle oddíl?". Nebo nechcete, aby vám správce souborů mazal nevratně soubory po stisknutí delete bez potvrzení.Takovehle hlasky nastesti nikde nemam a doufam, ze se to nezmeni. K cemu ta hlaska je, to jako testuje, jestli jsem behem par us, nez se objevi, nezmenil nazor?
... nebo vám na ní nešlápl kocour.Tohle je bezesporu zásadní problém. Ty bestie chlupaté se totiž strašně rádi válí na klávesnici na které právě někdo pracuje a program který to nebere v potaz je jednoduše špatně navržen.
mkfs
se neptá, jestli má formátovat, prostě konzolové aplikace předpokládají, že víte, co děláte. Pokud chcete něco, co se ptá, použijte klikací aplikaci.
Jo, to zamykání, to je věc. x264 se pro Windows kompiluje pomocí MinGW (Ming Nemilosrdný...), takže to pochytilo tyhle unixové móresy. Už se mi stalo, že při nechtěném spuštění další instance enkodéru přepsalo druhé x264 tomu prvnímu jeho výstupní soubor (o velikosti několika GB). Ani jedna z instancí si vůbec nevšimla, že se děje nějaká nepravost (i když došlo k totálnímu znehodnocení výstupu) a vesele pokračovaly v už zbytečném enkódování. Bylo to svým způsobem i legrační - ten enkodér, co byl pozadu, zkrátil výstupní soubor na nulu (a postupně pak začal přidávat), pak ten první enkodér, který už měl několik giga hotových, když chtěl zapsat další data, zase začal zapisovat tam, kde si myslel, že předtím skončil, čímž se soubor opět nafoukl nulami na původní velikost... akorát teď nevím, jestli pak ten druhé enkodér přepisoval vnitřek toho souboru, nebo pořád zkracoval.Todle chovani je velmi zadouci v pripade, ze chcete zkratit logovaci soubor nejakeho demona.
Hele, chapu, ze te jednou vypekl x264 encoder, ale spravne reseni by bylo, aby se te zeptal jestli chces pokracovat, i kdyz soubor uz existuje (na to je v unix konvenci prepinac -f).-f/--force obvykle znamená pravý opak :)
Tak tak, říkal jsem to už u několika minulých Zpravodajů, nejde jen o -4, ale často i třeba o -2 nebo -3. Tak třeba NFS: WC - autor "garbage" hodnocení podle všeho nečetl ani druhý post, který jasně říká, co dělat.
Prakticky se stává velmi zřídka, že by se zhoršila podpora pro nějakou hru / aplikaci. Mě se to stalo jen u SW: Jedi Academy, která mi na wine 1.1.x fungovala bez problémů a workaroundů, a na 1.3.x se mi ji nepodařilo rozjet. Na 1.5.x to podle všeho zase funguje.