Jiří Eischmann v příspěvku na svém blogu představuje typy, jak lépe chránit své soukromí na mobilním telefonu: "Asi dnes neexistuje způsob, jak se sledování vyhnout úplně. Minimálně ne způsob, který by byl kompatibilní s tím, jak lidé technologie běžně používají. Soukromí ovšem není binární věc, ale škála. Absolutního soukromí je dnes na Internetu dost dobře nedosažitelné, ale jen posun na škále blíže k němu se počítá. Čím méně dat se o vás posbírá, tím nepřesnější budou vaše profily a tím méně budou zneužitelné proti vám."
Byla vydána nová stabilní verze 25.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Warbler. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Multiplatformní open source spouštěč her Heroic Games Launcher byl vydán v nové stabilní verzi 2.17.0 Franky (Mastodon, 𝕏). Přehled novinek na GitHubu. Instalovat lze také z Flathubu.
Organizace Apache Software Foundation (ASF) vydala verzi 26 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Klávesnice IBM Enhanced Keyboard, známá také jako Model M, byla poprvé představena v roce 1985, tzn. před 40 lety, s počítači IBM 7531/7532 Industrial Computer a 3161/3163 ASCII Display Station. Výročí připomíná článek na zevrubném sběratelském webu Admiral Shark's Keyboards. Rozložení kláves IBM Enhanced Keyboard se stalo průmyslovým standardem.
Vyšlo Pharo 13 s vylepšenou podporou HiDPI či objektovým Transcriptem. Pharo je programovací jazyk a vývojové prostředí s řadou pokročilých vlastností.
Java má dnes 30. narozeniny. Veřejnosti byla představena 23. května 1995.
1. července Mozilla vypne službu Fakespot pro detekci podvodných recenzí v internetových obchodech. Mozilla koupila Fakespot v květnu 2023.
8. července Mozilla vypne službu Pocket (Wikipedie) pro ukládání článků z webu na později. Do 8. října si uživatelé mohou vyexportovat data. Mozilla koupila Pocket v únoru 2017. Několik měsíců byl Pocket integrovanou součástí Firefoxu.
Turris OS má aktuálně problém s aktualizací související s ukončením podpory protokolu OCSP u certifikační autority Let's Encrypt.
Od posledního dílu Zpravodaje o Víně vyšly čtyři nové (vývojové) verze Wine.
Wine 1.5.11 vyšlo 17. srpna s těmito změnami:
Wine 1.5.12 vyšlo 31. srpna s těmito změnami:
Wine 1.5.13 vyšlo 14. září s těmito změnami:
Wine 1.5.14 vyšlo 28. září s těmito změnami:
Právě takovýto titulek měl e-mail od Andyho Ritgera, vývojáře proprietárních grafických ovladačů NVIDIA. NVIDIA, kromě toho, že se konečně posunula k RandR 1.2, má zjevně zájem i o to, aby věci dobře fungovaly i v aplikacích pod Wine.
Proběhnuvší debata je současně zajímavým náhledem do toho, jak RandR 1.2 funguje a jaké překážky aplikace používající toto novější rozhraní musí řešit.
Ve verzi 302.xx jsme konečně přidali podporu RandR 1.2 do ovladače pro X od NVIDIA. Současně jsme přepracovali některé věci kolem validace časování režimů (modetiming) a jejich konfigurace ovladačem NVIDIA. Důležitou částí je to, že jsme odstranili implicitní škálování na plochých displejích a místo toho jsme umožnili explicitní konfiguraci skrze MetaModes a RandR 1.2. Pro uživatele se mění jen to, že v seznamu pro výstup RandR jsou pouze režimy získané z EDID displeje.
Trochu informací: modení GPU (alespoň NVIDIA, ale ostatní pravděpodobně také) mají flexibilní zpracování škálování, které se skládá z:
Pokud tedy například váš monitor zvládá režim 1920x1200 a vy chcete mít desktop o rozlišení 1280x720 se škálováním dle poměru stran, aby naplnil 1920x1200 (tedy 1280x720 škálované na 1920x1080 s 60 prázdnými řádkami nad a pod v režimu 1920x1200), tak byste v syntaxi MetaModes od NVIDIA mohli udělat:
„1920x1200 { ViewPortIn = 1280x720, ViewPortOut = 1920x1080+0+60 }“
Ačkoliv je syntaxe MetaModes specifická pro NVIDIA, toho samého lze dosáhnout přes RandR:
V praxi to znamená, že většiny rozlišení (tedy ne jen fixní seznam režimů) z pohledu velikosti desktopu je možné v RandR dosáhnout.
Mé otázky:
1920 x 1200 1920 x 1080 1600 x 1200 1280 x 1024 1280 x 720 1024 x 768 800 x 600 640 x 480
Dávalo by smysl, aby si uživatel mohl ve Wine určit konfiguraci RandR (aby měl obraz napříč výstupy RandR na obrazovce X)? To asi závisí na tom, jaké mechanismy pro konfiguraci runtime jsou možné.
Komunikace s Andym se ujal Henri Verbeet. Nejprve mu vysvětlil, že aplikace pro Windows si nevymýšlejí rozlišení samy, ale místo toho se zeptají na seznam dostupných a jedno si vyberou. Dále mu objasnil to, jak se mají věci řešit správně. Nejprve k vytváření seznamu standardních rozlišení:
[...] Řekl bych, že správným způsobem řešení by bylo generovat standardní režimy DMT apod. v jádře a použít vlastnost výstupu „scaling mode“ (režim škálování) pro ovládání škálování, tedy vlastně tak, jak to dělají ostatní ovladače.
A jak je to s určováním primárního výstupu?
Primární displej RandR by měl být CRTC 0, výstup 0. Uživatelé toto typicky mohou změnit přes xrandr nebo xorg.conf. Ale ne všechny ovladače se v tomto ve výchozím nastavení chovají rozumně, takže asi budeme muset přidat kód, kde vybereme první připojený displej pro primární displej Win32, pokud není v RandR žádný primární určen. Aktuálně ale používáme starší RandR, takže se to aspoň nechová hůř než dřív.
A co multihead?
Ano, náležitá podpora multihead je něco, co teprve musíme implementovat. Není ale mnoho aplikací, které by s vícero displeji dělaly něco užitečného, takže to teď nemá vysokou prioritu. Henri:
class="kt_citace" [...] S RandR 1.1 dostáváte jednu velikou obrazovku a můžete si vybrat mezi fullscreen aplikací roztaženou přes všechny displeje, nebo vypnout všechny displeje až na jeden. Ve skutečnosti jde o to, aby si aplikace mohla vybrat mezi fullscreen na konkrétním displeji nebo více displejích, pokud to aplikace podporuje, a všechno ostatní nechala být.
Mimochodem, smyšlené obnovovací frekvence generované z „DynamicTwinView“ také nejsou zrovna ku pomoci. Některé Win32 aplikace očekávají, že režimy 800x600 @60 Hz nebo 1024x768 @60 Hz vždy existují, a pokud ne, tak prostě umřou.
Dále se pokračovalo v diskuzi o tom, jak to podle standardu s primárním výstupem RandR vlastně je. Jak je to ale tedy bude s tím s multiheaded? Andy:
Souhlasím, že displeje, které Wine nepoužívá, by mělo Wine nechat být a ne je vypínat. Ale jak jsi řekl výše, tak většina Win32 aplikací nativně nevyužívá možností multihead systémů. Očekával bych, že by ale někteří uživatelé mohli chtít, aby jejich Wine aplikace běžela napříč vícero displeji. Nezní to snad rozumně?
Henri nevidí v multihead významný „use case“ pro uživatele Wine, zatímco Andy zase nechce, aby uživatelé najednou nemohli dělat něco, co s RandR a hackem v podobě MetaModes mohli. Na to Andy reaguje:
Protože máme odlišné pohledy na věc, což jen tak rychle nevyřešíme, co kdybychom jako kompromis přidali možnost, jak nechat uživatele vynutit RandR 1.1 místo RandR 1.2? Tak by uživatelé alespoň mohli dosáhnout určitých konfigurací, které jinak nepůjdou. Pokud to zní přijatelně, jaký je preferovaný mechanismus pro něco takového? Obyčejná proměnná v prostředí?
Na to Henri odpověděl, že by byla lepší hodnota „UseXRandR“ v registrech. U multihead je zásadním problémem absolutní svoboda, kterou s novým RandR aplikace mají – musí si totiž úplně všechno řešit samy, anebo se musí uživatel spokojit s tím, že nebude mít možnost nastavit to, co chce. Na Windows se tento problém v ovladačích NVIDIA řeší podobně jako na Linuxu s MetaModes. Andy pak odkázal na článek, který ve stejnou dobu náhodou vyšel na Phoronixu. Z něj vyplývá, že problém fullscreen aplikací na multihead je něco o čem se ví. A zde by mohla pomoci nějaká knihovna, do které by se soustředily snahy nadefinovat rozumné chování a usnadnit konfiguraci.
I když na druhou stranu – kolik z vás by rádo mělo hru přes několik displejů?
Současný princip fungování Wine je předurčen spíše k tomu, aby si sami uživatelé instalovali aplikace do svých prefixů v HOME. Objevuje se ale problém s „globální“ instalací aplikací pro Windows do umístění, kam mohou přistupovat všichni uživatelé – ale už tam nemohou zapisovat, a to je kámen úrazu.
Řekl bych, že mám platné využití pro ignorování [kontroly vlastnictví prefixu] a rád bych věděl, jaký patch by prošel.
Představte si distribuci obsahující hru pro Windows v podobě read-only kopie nainstalovaného prefixu (řekněme do /opt). Když uživatel spustí aplikaci (přes soubor .desktop), tak se spustí skript, který udělá následující:
To teď funguje docela dobře: nové (nebo upravené) soubory v prefixu jsou uloženy do ~/.aplikace, odkud se obnoví při příštím spuštění aplikace. Různí uživatelé mohou mít aplikaci spuštěnou souběžně, neboť mají každý svůj vlastní prefix. Vyhýbáme se zbytečnému kopírování souborů, protože se do domovského adresáře ukládají jen soubory změněné uživatelem.
Má to ale jeden velký háček: unionfs zobrazuje vlastníka jako root, dokud uživatel soubor neupraví/neokopíruje. To znamená, že Wine odmítne spuštění z prefixu pod obyčejným uživatelem. Zakomentování této části kódu Wine to krásně rozchodí, ale rád bych viděl řádné řešení.
Bylo by tu přijatelné něco jako přepínač pro Wine nebo proměnná v prostředí?
Francois Gouget měl nápad, že by stačilo udělat touch na soubor v prefixu a rázem by se změnila práva adresáře prefixu. Scott na to ale řekl:
unionfs bohužel vykazuje smíšenou strukturu práv: soubory jsou vlastněné uživatelem, jakmile byly upraveny, ale samotný název hostujícího adresář není možné takto upravit, což je právě to, co Wine kontroluje.
Jörg Höhle by na to šel úplně jinak. Jeho návrhem je zapsat si bokem všechny klíče v registrech, co instalátor aplikace vytvoří, dále pak všechny soubory, co vytvoří mimo instalační adresář. Samotný instalační aderesář pak pomocí symbolického odkazu dostat do profilu uživatele, kam se nakopírují i ostatní soubory a zapíší data do registru.
Řešení to také je, třebaže složité, jenže Scott na to napsal:
Vypnutí [této kontroly] řeší úplně všechny problémy, na které narážím, aniž bych musel dělat cokoliv složitého nebo něco řešil ručně.
Jak to tedy bude? Zatím se neví.
Krátce po sobě vyšlo Wine Mono 0.0.6 a 0.0.8, ta první jmenovaná verze byla pokažená. Toto je přehled změn od verze 0.0.4:
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Při pohledu na dlls/winex11.drv/xrandr.c zjišťuji, že seznam režimů prvního RandR CRTC/výstupu je používán pro vytvoření výčtu dostupných režimů ve Wine. Probíhá komunikace mezi Wine a aplikacemi pro Windows vždy tak, že musíte hlásit seznam tvořený prvky (šířka, výška, obnovovací frekvence)? Nebo někdy aplikace říkají Wine, jaké rozlišení samy chtějí?Aha, takže nVidia dělá své uzavřené ovladače na Linux pro platíc business zákazníky. Aha. A teď prosím tu o karkulce.
Wine MonoWindows Mono, Unix Mono, Wine Mono,… já už se v tom pomalu ztrácím.
1. zrusili GPU skalovani - misto toho aby se mi male rozliseni zobrazilo hezky s cernymi okraji, rozplzne se po celem velkem monitoru.Je v metamodes.
1. zrusili GPU skalovani - misto toho aby se mi male rozliseni zobrazilo hezky s cernymi okraji, rozplzne se po celem velkem monitoru. A pritom tohle byl krok vstric standartum. Nevim jestli ma na to ten skvely genialni RandR reseni.
xrandr --output LVDS --set 'scaling mode' 'Full Aspect'