Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
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'