Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Od posledního vydání Zpravodaje o Víně uplynulo mnoho času. Nemusíte se ale bát, že bychom přeskočili důležité dění. Každopádně vyšla celá řada nových verzí Wine – žádné stabilní, jen samé vývojové. Podívejme se na dvě poslední:
Wine 1.3.28 vyšlo 9. září 2011 s následujícími novinkami:
Wine 1.3.29 vyšlo 23. září 2011 s následujícími novinkami:
O DIB enginu už slýcháme velmi dlouho. Připomeňme, že jeho existence je zásadní pro (nyní dost nízký) výkon vykreslování klasických okenních aplikací. Po řadě zavržených implementací se nyní do Wine konečně postupně jedna dostává. Massimo Del Fedele je autorem jedné ze zavržených implementací a teď ho zajímá, jak postupuje práce na té vyvolené:
V poslední době jsem zpozoroval mnoho patchů souvisejících s DIB enginem, sestavil jsem si poslední verzi zdrojáků a vyzkoušel jsem to... Žádné zlepšení výkonu v AutoCADu, mé testovací aplikaci. Takže by mě zajímalo, jestli už engine funguje, aspoň částečně, nebo nefunguje vůbec. Pokud funguje, je třeba nějaký přepínač/hodnota proměnného prostředí pro zapnutí?
Omlouvám se, že se tu tak vyptávám, ale kromě git commitů jsem neviděl žádné vysvětlení, co se děje. I některé uživatele mého starého enginu, co jsou nuceni používat starou verzi Wine (už jej kvůli nedávným změnám nelze aplikovat na současnou verzi), by zajímalo, co se děje.
Odpověděl mu Octavian Voicu, který ale upozorňuje, že vychází jen z commitů a vlastního zkoumání kódu:
Většina doposud udělané práce byla na úrovni architektury – vytváření infrastruktury, která zvládne inkrementální vývoj DIB enginu (viz dlls/gdi32/dibdrv/). Nový DIB engine je standardně povolen a je aktivován automaticky (přidán na zásobník ovladačů), pokud SelectObjectu předáte DIB. Když DIB engine nějakou funkci neimplementuje, je předána dalšímu ovladači na zásobníku. Pokud nejsou některé funkce podporovány (např. specifické formáty pixelů; styly pera nebo štětce), opět se volání přesune na další ovladač na zásobníku, kdykoliv je tyto funkce třeba použít (např. při kreslení čáry, když není aktuální pero podporováno).
Aktuální stav je:
Faktem je, že jedinými primitivy, která jsou aktuálně implementována, jsou LineTo, Rectangle, PaintRgn a PatBlt, minimum potřebné pro ozkoušení, že pera a štětce správně fungují; žádné blity; žádné polygony, ani další podivné tvary; žádné kreslení fontů; dokonce ani ne get/set pixel. To je asi důvod, proč AutoCAD ještě nejeví známky zlepšení. Na druhou stranu je většina zrádných architektonických věcí hotová, takže hádám, že viditelná zlepšení nejsou daleko.
Od odeslání tohoto e-mailu se věci posunuly dále, v posledních verzích už můžeme vidět např. podporu dalších Blt operací. Massimo řekl, že bez podpory fontů je jasné, že není v AutoCADu nic znát. James McKenzie se zapojil do debaty s návrhem:
Možná by stálo za to přepracovat kód nad opravami od Huwa tak, aby tvé patche fungovaly, než Huw dokončí svou práci.
Tohle by ti pomohlo s rozjezdem, kdyby se Huw rozhodl, že tvůj kód je lepší než jeho!
Massimo ale odpověděl, že přístup Huwa je příliš odlišný od jeho na to, aby taková věc byla možná. Dále k tomu napsal:
[...] Navíc, z toho (mála samozřejmě), co jsem pochopil z titulků patchů, některé nízkoúrovňové primitivy byly vyexportovány z winex11 – ovladačů gdi32, což je věc, o které mi bylo řečeno, že je „nemožná“, když jsem vyvíjel svůj DIB engine, a umožňuje snadno vyřešit ten největší zbývající problém, totiž efektivní DIB-DDB konverzi.
Takže si počkám na to, co se bude dít s Huwovým enginem. Je to škoda, protože poslední pokrok ve Wine vyřešil mnoho jiných problémů nesouvisejících s DIB. Uživatelé AutoCADu mohou prozatím doufat, že primitivy fontů budou brzo začleněny 
Nowres Rafid navrhl, že by soubory .bat a .com měly být v GNOME, KDE a dalších asociovány s wine cmd. Na tento návrh zareagoval Damjan Jovanovic:
COM soubory jsou AFAIK samostatný prehistorický DOSový kód reálného režimu bez možnosti načítat DLL. Neměly být spíše načítány DOSBoxem, kam na architektuře AMD64 stejně posíláme DOSové aplikace?
BAT soubory by se měly asociovat s Wine, ale při dvojkliku na Windows se spustí v terminálovém okně (když jsem to posledně zkoušel). Takže bychom museli vytvořit nový wine-cmd.desktop, který se asociuje s BAT soubory. Mrknu na to.
Když už jsem u toho, EXE soubory také čistě nepatří Wine – mohou to být DOS programy reálného režimu nebo .NET kód určený na *nixech Monu. Někdy budou muset Wine/Mono/DOSBox a související projekty začít mluvit o nějakém rozhodovacím mechanismu.
Vincent Povirk poskytl další informace:
Nejsem si jistý, že DOSBox jen tak otevře nějaký náhodný soubor. Museli bychom vytvořit konfigurační soubor, který nastaví mapování jednotek, spustí soubor a ukončí se. Pokud Wine dokáže takové věci dělat (a možná také ošetřit situace, kdy binárka COM očekává, že je spouštěna na stroji s Windows, například DOSovém stroji s nainstalovanými Win3.1), přijde mi to jako dobrá volba.
Je tu nenulová šance, že wine start /unix pro soubory BAT doopravdy spustí cmd a vytvoří terminál. Dělá to pro konzolové aplikace. Pokud tak nečiní, je tu možnost, že to start.exe udělá na Windows, v tomto případě je to chyba ve Wine, kterou bychom měli opravit. Měl bys to ozkoušet, než začneš dělat něco nového.
Na #mono (nebo #monodev) se o tom mluvilo ve smyslu, že rozhodovací mechanismus se nazývá MIME typy a DOS exe, x86/x64 PE exe a CLR exe jsou všechny odlišné a měly by mít odlišné MIME typy.
Damjan to ozkoušel a zjistil, že zatímco na Windows dvojklik zaručuje automatické zavření okna a „start“ znamená, že zůstane otevřené, na Wine „start“ způsobuje automatické zavření. Dále se někdo další zeptal, zda je možné typy EXE binárek nějak snadno rozlišit u shared-mime-info, na což Damjan odpověděl:
Parsování hlaviček EXE vyžaduje následování ukazatelů (například musíš jít na offset určený v dwordu e_lfanew v IMAGE_DOS_HEADER na offsetu 0x40 v souboru, aby ses dostal na rozšířenou hlavičku, která v případě binárky Win16 začíná na „NE“). Zatímco „file“ toto dokáže a „man 5 magic“ obsahuje dokonce příklady, jak to je udělané u EXE souborů, jednoduché parsování prováděné u shared-mime-info zjevně ukazatele následovat nedovede.
Diskuze na toto téma pak brzy utichla. Ozval se ale André Hentschel, který dal vědět, že na podpoře DOSBoxu pracuje (winevdm/winevdm.c:start_dosbox).
Scott Ritchie informuje, že pro snazší testování je nyní možné si na Ubuntu snadno nainstalovat poslední verzi Wine z Gitu. Oproti běžné instalaci se namísto ppa:ubuntu-wine/ppa přidává repozitář ppa:ubuntu-wine/daily. Instalace pak může vypadat následovně:
sudo add-apt-repository ppa:ubuntu-wine/daily sudo apt-get update sudo apt-get install wine1.3
Na mailing listu Wine se rozhořela debata o podpoře iTunes ve Wine, která vlastně nikdy nebyla úplná. Především možnost kopírování dat do iPodů, iPhonů a podobných je pak důvodem, proč by si někdo tento software na Linuxu instaloval – a právě to nefunguje.
Keith Curtis vyvolal dohady tím, že prohlásil, že by práci na podpoře iTunes měli vývojáři dát prioritu. Samozřejmě, kdykoliv někdo začne dobrovolníkům říkat, co by měli ve svém volném čase dělat, nedopadne to dobře. I tak se později vyjasňování a srovnávání dostalo k produktivní diskuzi.
Zatímco starým iPodům stačilo standardní USB Mass Storage, nová zařízení od Apple vyžadují přímou komunikaci přes USB. Na tom se pracuje, ale je to běh na dlouhou trať. A právě autor této podpory, Damjan Jovanovic, popsal v dlouhém e-mailu, jak se věci mají:
Jako člověk, co pracoval v Microsoftu, vám říkám, že byste všichni měli docenit velikost a komplexnost architektury ovladačů na Windows. Proto bych řekl, že toto „selhání“ je především kvůli rozsáhlosti problému, který se tu řeší.
Moje první pokusy o přidání podpory USB do Wine byly bolestivé a pomalé. V roce 2006 mé první patche zaslané do Wine řešily problémy v SETUPAPI.DLL. Kolem roku 2007 mé hacky ve Wine a linuxovém jádře pro emulaci USBSCAN.SYS umožnily mému user-space USB vypisovači pro Windows, aby fungoval pod Ubuntu 6.06. Některé z těchto hacků byly nakonec pročištěny a dostaly se v roce 2009 do Wine STI.DLL, ale můj patch jádra nikdy nefungoval na jiné verzi jádra a pochybuji, že by ve Wine nebo linuxovém jádře přijali ten pochybný kód, co jsem používal. Začal jsem zkoumat možnost implementování USBSCAN jako ovladače v uživatelském prostoru s něčím jako FUSE, ale pak Wine získalo základní NTOSKRNL.EXE a schopnost načítat SYS soubory pro Windows. Od té doby bylo cílem implementovat vše ve Wine a pro USB I/O použít libusb.
V roce 2010 jsem do Wine přidal některé funkce z USBD.SYS a hlavičkové soubory pro USB. Později jsem se pokusil přidat podporu libusb, monitorování USB zařízení a základní infrastrukturu načítání ovladačů podle potřeby, ale nic z toho nebylo z různých důvodů do Wine přijato. Nyní se postupně snažím zobecnit načítání ovladačů ve Wine. Pak snad přidám načítání ovladačů při připojení USB zařízení. Pak podporu libusb. Pak teprve přidám samotné základní USB I/O. Pak musím rozchodit ReadFile/WriteFile u ovladačů. A stejně pak zbude nutnost napsat vysokoúrovňové ovladače (např. USBSCAN.SYS) a spousta chyb v SETUPAPI.DLL a funkce jako podpora instalátorů tříd [class installers], které bude nutné přidat, než se ovladače vůbec úspěšně nainstalují. A pak budeme doufat, že nezačnou používat příliš mnoho neimplementovaných funkcí z NTOSKRNL.EXE.
Takže to postupuje pomalu a musí se toho udělat hodně a moc vývojářů Wine se o to nezajímá. Můžeme jen doufat, že jakmile nějaké ovladače začnou fungovat, vyvolá to větší zájem o Wine (a Linux) a do Wine pak půjde více patchů .
Damjan se po dalších několika e-mailech, které mailing listem proběhly, rozloučil se slovy, že se ozve, jakmile bude mít gitový strom, ve kterém bude něco zajímavého.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
12.10.2011 00:23
D.A.Tiger | skóre: 8
| Brno
Já nevím, ale co je prehistorického na BAT souborech?Sorry, mozna jsem neco prehledl, ale v clanku se oznacuji jako prehistoricke COM soubory, ne bat(aky)... "COM soubory jsou AFAIK samostatný prehistorický DOSový kód reálného režimu ..."
12.10.2011 01:29
D.A.Tiger | skóre: 8
| Brno
12.10.2011 23:23
D.A.Tiger | skóre: 8
| Brno
15.10.2011 22:39
PaulosV | skóre: 10
| blog: dentoob
15.10.2011 22:58
PaulosV | skóre: 10
| blog: dentoob
Taková mohutná zpětná kompatibilita se opravdu jen tak nevidí. Ale BAT soubory už neotvírá, tím jsem si celkem jistý.
16.10.2011 00:42
D.A.Tiger | skóre: 8
| Brno
12.10.2011 09:20
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
12.10.2011 09:09
13.10.2011 12:42
