Byla vydána nová stabilní verze 24.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Uakari. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Byla vydána nová verze 1.48.0 sady nástrojů pro správu síťových připojení NetworkManager. Novinkám se v příspěvku na blogu NetworkManageru věnuje Fernando F. Mancera. Mimo jiné se v nastavení místo mac-address-blacklist nově používá mac-address-denylist.
Před 25 lety, 31. května 1999, započal vývoj grafického editoru Krita (Wikipedie). Tenkrát ještě pod názvem KImageShop a později pod názvem Krayon.
Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 24.05.0 editoru videa Kdenlive (Wikipedie). Ke stažení brzy také na Flathubu.
David Revoy, autor mj. komiksu Pepper&Carrot, se rozepsal o své aktuální grafické pracovní stanici: Debian 12 Bookworm, okenní systém X11, KDE Plasma 5.27, …
Wayland (Wikipedie) byl vydán ve verzi 1.23.0. Z novinek lze vypíchnout podporu OpenBSD.
Craig Loewen na blogu Microsoftu představil novinky ve Windows Subsystému pro Linux (WSL). Vypíchnout lze GUI aplikaci pro nastavování WSL nebo správu WSL z Dev Home.
V sobotu 1. června lze navštívit Maker Faire Ostrava, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Webový server Caddy (Wikipedie) s celou řadou zajímavých vlastností byl vydán ve verzi 2.8 (𝕏). Přehled novinek na GitHubu.
Byla vydána verze 3.0 (@, 𝕏) svobodného softwaru HAProxy (The Reliable, High Performance TCP/HTTP Load Balancer; Wikipedie) řešícího vysokou dostupnost, vyvažování zátěže a reverzní proxy. Detailní přehled novinek v příspěvku na blogu společnosti HAProxy Technologies.
Od posledního dílu Zpravodaje o Víně vyšly čtyři nové (vývojové) verze Wine.
Wine 1.5.7 vyšlo 22. června s těmito novinkami:
Wine 1.5.8 vyšlo 3. července s těmito novinkami:
Wine 1.5.9 vyšlo 17. července s těmito novinkami:
Wine 1.5.10 vyšlo 31. července s těmito novinkami:
Dan Kegel upozornil na milník, kterého se podařilo 64bitovému Wine dosáhnout:
Právě jsem narazil na CAD aplikaci, jejíž 64bitová verze běží lépe než ta 32bitová (32bitová se zasekne kvůli #31358, ale 64bitová se přes to dostane a vypadá to, že i něco dělá).
Není to tak důležité, ale je to fajn.
GCC 4.7 přináší zajímavá vylepšení, v souvislosti s ním se slýchá asi hlavně o LTO (Link Time Optimization). U Wine ale nejde ani tak o LTO, jako spíše o to, aby to vůbec fungovalo. Scott Ritchie:
Wine je posledním balíčkem v aktuálním Ubuntu alpha, který stále závisí na GCC 4.5, bylo by pěkné se GCC 4.5 zbavit a přeportovat Wine, jenže i o 4.6 se ví, že to moc nefunguje.
Ale teď tu máme 4.7 – ví se v souvislosti s tím o nějakých chybách?
Eric Pouech vysvětlil, že překážkou může být i jedna další novinka:
Pokud vím, tak GCC 4.7 nastavuje dwarf4 jako výchozí formát pro ladící informace, zatímco wine (dbghelp) umí jen dwarf2. Způsobuje to spoustu nepřehledných backtrace ve winedbg.
Začal jsem do Wine přidávat podporu dwarf4, ale zatím se neradujte (bude to náročné a pracné a vyžádá si to docela dost oprav v dbghelp) (a nemám teď moc času).
Scott Ritchie se tedy rozhodl dwarf4 manuálně zakázat (respektive nastavit natvrdo používání dwarf2). Dan Kegel poukázal na spoustu jiných problémů s novými GCC (s verzí 4.7 se to „samo“ neopravilo) – kromě toho, že je standardně zapnuté -fomit-stack-pointer, kompilátor také na některých místech padá se SIGSEGV.
Caleb Hearon nakousnul téma hry Diablo III a banů, které firma Blizzard údajně dávala uživatelům Wine, typicky za používání nepovoleného softwaru třetí strany.
[...] A pak se to dostalo na úvodní stranu na Redditu s 25 tisíci hlasy!
Pravděpodobně jde o chybu na straně Blizzardu. Ale myslel jsem si, že by to mohlo být zajímavé i pro lidi tady. Je úžasné, že tato diskuze, kterou jsem vedl, zatímco jsem byl v práci, vedla k rozšíření povědomí o Wine (jeden z top komentářů na Reddit se ptá, co to Wine je).
A Wine hackeři – skvělá práce, právě jsem 2 hodiny hrál Diablo III a běží to výborně.
Kupodivu zareagoval jen jediný člověk. Erich E. Hoover:
Také jsem nějakou dobu úspěšně hrál Diablo III a dotýká se mě, že se z toho stalo takové mediální šílenství. Je docela dost dobře možné, že lidé dostali ban za neoprávněný přístup ke svému účtu nebo jednoduše za cheatování.
Přijde mi, že rovnou z toho vinit Blizzard je rychlá cesta, jak získat spoustu negativní publicity a právě to by je mohlo vést k tomu úmyslně znemožňovat fungování pod Wine, aby k podobným problémům v budoucnu nedocházelo.
Ilyu Konstantinova zajímala možnost používání Wine při portování aplikací na Linux postupným způsobem, zejména k doplňování „chybějících“ funkcí.
[...] Hledám něco skromnějšího – knihovnu pro snadné portování, která implementuje funkce, které v glibc samotném nejsou – např. _wfopen, _wgetenv. Pravdou je, že spoustu funkcí je možné dodat jednoduchým #define na jejich obdobu v glibc. (Ale je to samozřejmě nutné dělat opatrně.)
Existuje něco takového?
Vincent Povirk vysvětluje, že winelib je spíše pro ty, co vlastně portovat nechtějí.
Přijde mi, jestli nepoužíváte winelib nevhodným způsobem.
Winelib není užitečným mezikrokem při portování existující aplikace na Linux, protože většina práce spojená s portováním na winelib vám nijak nepomáhá s nativním linuxovým portem. V určitém bodě se musíte od Windows plně odloučit a winelib na tom nic nezmění. Jen vám dává způsob, jak tento bolestivý krok odsouvat, aniž by s bolestí, až na to dojde, pomohlo.
Navíc běh existujícího kódu pro Windows s winelib nemá oproti běhu Windows exe nebo dll pod Wine typicky žádné výhody. Ačkoliv je pravda, že se dá winelib použít k portování kódu pro Windows na nové architektury, které MSVC nepodporuje, není to zrovna něco, o co by byl zájem.
Většina lidí, kteří chtějí použít winelib, to chtějí kvůli jedné z těchto věcí a neuvědomují si, že winelib neřeší žádné z jejich problémů. Winelib nemá skoro žádné využití pro sestavování existujícího kódu pro Windows. Vzhledem k tomu pak zlepšování kompatibility winelib s Windows na úrovni zdrojového kódu není moc užitečné a nikomu to asi nestojí za ten čas.
Winelib je nejlepší pro podporování omezeného množství nového kódu (jediné .dll.so nebo .exe.so), které funguje jako most mezi Linuxem a Windows.
Tazatel nebyl tímto vysvětlením odrazen. Vincent jej odkázal na libwapi v Mono jako dost dobře lepší věc pro jeho účel. Nakonec ale našli společnou řeč, což vedlo k závěrečnému dotazu:
Pokud mám kód, který je potřeba napsat nativně pro provázání aplikace pro Windows s Linuxem (např. pro používání nějakých nízkoúrovňových linuxových záležitostí), mohu to sestavit jako knihovnu pomocí wineg++ / winelib a používat to z aplikace spuštěné pod Wine?
Vincent už jen potvrdil, že to je přesně to, k čemu se dá winelib dobře využít.
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
Off-screem vykreslování je nyní v Direct3D výchozí volbouNeměl autor na mysli Off-screen? Jinak co se týče Winelib, je možné, že to není úplně ta "nej, nej cool cesta", ale dřív jsem používal Wine právě pro testování a odlaďování aplikací které jsem chtěl portnout na Widle. Co mi běželo v pohodě na Wine, mi běželo absolutně bez problémů na Windows... Nevím tedy jak je tomu teď, protože už dlouho se portováním na Widle nezabývám (jednak je už dávno nepoužívám a jednak, dost vývojářů, kteří používají multiplatformní freemworky na widlích na nás taky stejně z vysoka kašle... )
Od tý doby co jsem si pohrál s nastavením KVM QEMU jsem nadmíru spokojenej a nemám potřebu hledat jiný řešení.
bez moznosti uzivatelu pridavat nove bez schvaleni.To přidávání štítků někomu funguje? Mně teda už min. půl roku ne.
"IMO celkově dost postrádají smysl. Osobně bych to dal pryč."Zas až tak bych to nehrotil. Osobně jich využívám když hledám informace (mimo vyhledávače), je to pro mě někdy dokonce lepší, než odkazy pod články. Ale probrat by potřebovaly, to je fakt.
Jsou automatickýJak jsou generovany automaticky? Kdyz se kouknu na nektere stitky, jsou "podedene" z naprosto nesouvisejich clanku.