Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
Byla vydána nová verze R14.1.4 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek i s náhledy v poznámkách k vydání. Podrobný přehled v Changelogu.
Bylo vydáno OpenBSD 7.7. Opět bez písničky.
V Tiraně proběhl letošní Linux App Summit (LAS) (Mastodon). Zatím nesestříhané videozáznamy přednášek jsou k dispozici na YouTube.
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.