Google bude vydávat zdrojové kódy Androidu pouze dvakrát ročně. Ve 2. a 4. čtvrtletí.
Bezpečnostní specialista Graham Helton z Low Orbit Security si všímá podezřelých anomálií v BGP, zaznamenaných krátce před vstupem ozbrojených sil USA na území Venezuely, které tam během bleskové speciální vojenské operace úspěšně zatkly venezuelského diktátora Madura za narkoterorismus. BGP (Border Gateway Protocol) je 'dynamický směrovací protokol, který umožňuje routerům automaticky reagovat na změny topologie počítačové sítě' a je v bezpečnostních kruzích znám jako 'notoricky nezabezpečený'.
Společnost Valve aktualizovala přehled o hardwarovém a softwarovém vybavení uživatelů služby Steam. Podíl uživatelů Linuxu dosáhl 3,58 %. Nejčastěji používané linuxové distribuce jsou Arch Linux, Linux Mint a Ubuntu. Při výběru jenom Linuxu vede SteamOS Holo s 26,32 %. Procesor AMD používá 67,43 % hráčů na Linuxu.
V Las Vegas probíhá veletrh CES (Consumer Electronics Show, Wikipedie). Firmy představují své novinky. Například LEGO představilo systém LEGO SMART Play: chytré kostky SMART Brick, dlaždičky SMART Tagy a SMART minifigurky. Kostka SMART Brick dokáže rozpoznat přítomnost SMART Tagů a SMART minifigurek, které se nacházejí v její blízkosti. Ty kostku SMART Brick aktivují a určí, co má dělat.
Vládní CERT (GovCERT.CZ) upozorňuje (𝕏) na kritickou zranitelnost v jsPDF, CVE-2025-68428. Tato zranitelnost umožňuje neautentizovaným vzdáleným útočníkům číst libovolné soubory z lokálního souborového systému serveru při použití jsPDF v prostředí Node.js. Problém vzniká kvůli nedostatečné validaci vstupu u cest k souborům předávaných několika metodám jsPDF. Útočník může zneužít tuto chybu k exfiltraci citlivých
… více »V úterý 13. ledna 2025 se v pražské kanceláři SUSE v Karlíně uskuteční 5. Mobile Hackday, komunitní setkání zaměřené na Linux na mobilních zařízeních, kernelový vývoj a související infrastrukturu. Akci pořádá David Heidelberg.
… více »Už je 14 dní zbývá do začátku osmého ročníku komunitního setkání nejen českých a slovenských správců sítí CSNOG 2026. Registrace na akci je stále otevřená, ale termín uzávěrky se blíží. I proto organizátoři doporučují, aby se zájemci přihlásili brzy, nejlépe ještě tento týden.
… více »Rok 2026 sotva začal, ale už v prvním týdnu se nashromáždilo nezvykle mnoho zajímavostí, událostí a zpráv. Jedno je ale jisté - už ve středu se koná Virtuální Bastlírna - online setkání techniků, bastlířů a ajťáků, kam rozhodně doražte, ideálně s mikrofonem a kamerou a zapojte se do diskuze o zajímavých technických tématech.
Dějí se i ne zcela šťastné věci – zdražování a nedostupnost RAM a SSD, nedostatek waferů, 3€ clo na každou položku z Číny … více »Vývojáři GNOME a Firefoxu zvažují ve výchozím nastavení vypnutí funkce vkládání prostředním tlačítkem myši. Zdůvodnění: "U většiny uživatelů tento X11ism způsobuje neočekávané chování".
Nástroj pro obnovu dat GNU ddrescue (Wikipedie) byl vydán v nové verzi 1.30. Vylepšena byla automatická obnova z disků s poškozenou čtecí hlavou.
Od posledního vydání Zpravodaje o víně vyšly čtyři -rc verze následované finální verzí Wine 1.6. V -rc verzích šlo jen o malé opravy chyb, podíváme se tedy jen na krátké oznámení verze 1.6 (seznam změn je opravdu velmi dlouhý).
Toto vydání představuje 16 měsíců vývoje a okolo 10 000 jednotlivých změn. Mezi hlavní noviny patří nový ovladač Mac, úplná podpora pro průhlednost oken a nový balíček Mono pro podporu aplikací v .NET.
Reimplementovace API z jiných operačních systémů je náročný úděl – o tom není pochyb. Dokumentace ne vždy bývá nejlepší, někdy si může dokoce i protiřečit. Úplně nejhorší ale je, když nějaká aplikace závisí na chování původního API, které nebylo ani záměrem autorů tohoto API. Emulace těchto detailů se přitom může ukázat dosti náročnou. Člověk by rád řekl, že aplikace je prostě rozbitá, ale to není řešení. Michael Casadevall:
Pracuji na tom, aby Sid Meier's Civilization V (Civ5) fungovalo pod Wine relativně bez problémů. Největším problémem je to, že instalace největšího expansion packu pod Wine hru kompletně rozbila, pokud jsem nepoužil ošklivé hacky. Hlavním problémem je konkrétně to, že Civ5 načítá datové souboru v pořadí, jak je vrací Find{First,Next}File() a zblázní se, pokud je toto pořadí narušeno. Svá zjištění jsem popsal v bugu #34122.
Začal jsem hledat možné řešení, ale nejsem si jistý, co vlastně dělat. Na stránce na MSDN je jasně napsáno, že pořadí závisí na použitém systému souborů a googlení napovídá, že zatímco NTFS vrací soubory víceméně v abecedním pořadí, FAT32 je vrací podle data vytvoření a u síťových jednotek je to sázka do loterie. Dokonce se mi podařilo v Civ5 vyvolat podobné chyby tím, že jsem jej spustil ze síťového disku (kde jsem si předtím ověřil, že soubory nevrací seřazené). FindFirstFile v podstatě volá NtQueryDirectoryFile, které pak buď použije systémové volání nebo readdir, aby získalo seznam souborů v adresáři.
Michael dále popisuje, kde by provedl případné seřazení, ale celé mu to přijde špatně obzvláště, když jde o chybu v aplikaci, nikoliv ve Wine jako takovém. Na druhou stranu je pravda, že drtivé většině lidí na Windows hra bude fungovat. Na obhajobu takového „hacku“ dále říká: [...] nedivil bych se, kdyby se takový problém objevil i jinde.
Rico Schüller přišel se spoustou dalších otázek. Týkají se hlavně toho, jak by se chovalo NTFS pod Linuxem a jestli se to opravdu rozbije i na FAT32 (které se na Windows přece jen najde spíš než ext3). Kromě doporučení obrátit se na technickou podporu hry dodává:
Řekl bych, že dělání změn ve funkcích Find* je špatné, protože se zcela jistě najde aplikace, která bude záviset na pořadí podle data vytvoření na oddílech s FAT32...
Damjan Jovanovic by na to šel trochu jinak a pomohl si speciálním systémem souborů na bázi FUSE, který by řadil názvy souborů, jako je to na Windows. To se ovšem Michaelovi vůbec nelíbí – hlavně kvůli tomu, jak vinou takové hlouposti utrpí výkon. Přichází ale s jiným nápadem – zatím se k němu sice nikdo nevyjádřil, pravděpodobnost jeho přijetí je ale jistě vyšší, než kdyby se měla dělat úprava Wine s dopadem na všechny aplikace. Michael:
Ve světě Windows jsou tři věci, co se dají udělat v případě rozbité kompatibility s aplikací: změnit kód systému, napsat shim [obalení] nebo opatchovat aplikaci.
V současné době ve Wine můžeme měnit jen naše DLL; patchování aplikací za běhu je právně problematické a křehké. Proto, když je nějaká aplikace podobně rozbitá, nemáme pořádný způsob, jak to napravit. Proto navrhuji rozšířit Wine.
Během včerejších večerních debat se pracovalo na implementaci apphelp.dll, které obsahuje funkčnost databáze shimů. Dotyčný autor neměl v plánu ve Wine implementovat používání shimů, ale mám za to, že časem se bude objevovat více a více případů, kdy shim bude lepším řešením než zásah do knihoven Wine.
Michael na závěr uvedl, že v nejbližších dnech nebude mít čas se tomu do hloubky věnovat, ale chce navrhnout alespoň kus kódu, který by do budoucna mohl posloužit. Dále se pokusí problém řešit s výrobcem hry.
Wine se za uplynulá léta dostalo do stavu, kdy šance na fungování aplikace jsou nemalé. S aplikacemi závisejících na vlastnostech velmi specifických pro původní cílový systém to ale nebude nikdy procházka růžovým sadem. Pavel Píša problém s jednou takovou řeší; má ale tu výhodu, že má přístup ke zdrojovým kódům:
Spravujeme open source chromatografický software CHROMuLAN. Bohužel je napsaný v Delphi (ve verzi 6) a nemáme prostředky na portování na Linux, ačkoliv je Linux už 18 let naší hlavní vývojovou platformou pro návrh a vývoj embedded hardwaru. Naším dlouhodobým cílem je aplikaci přeportovat na Lazarus/FPC nebo dokonce přepsat do Qt, ale na tom teď dělat nemůžeme.
CHROMuLAN pod poslední verzí Wine naštěstí běží docela dobře. Máme ale problém s přístupem k hardwaru pro získávání dat.
Zařízení jsou k počítači připojena přes speciální protokol (uLAN) na síti RS-485. Máme dokonce ovladače pro Linux (první platforma), Windows (dokonce ozkoušeno na 64 bitech) a další systémy. Máme všechno pro PCI, konvertory RS-232/485 a přídavné karty PCI RS-485. Celé softwarové vybavení dokonce funguje pod ReactOS v QEMU. Wine je ale příjemnějším řešením, pokud někdo používá Linux jako svůj hlavní desktopový systém.
Pavel dále popisuje úsilí, co doposud vynaložil:
Napsal jsem DLL/SYS jako ovladač podporující veškerá IRP_MJ_xxx a ioctl ve stylu ovladače KMD/WMD a implementoval jsem funkce pomocí volání jejich ekvivalentů nad /dev/ulan.
Ale nefunguje to. Do ul_drv.sys se dostávají jen ioctl a i ta selhávají, protože kontext není správně nastaven. Ukazatel irpStack->FileObject je nastaven na 0x66666666.
Zbytek jeho žádosti o radu se zaměřuje na oblasti Wine, kde se pokusil najít obdobnou situaci, kterou by se mohl inspirovat. Na e-mail zareagoval Vincent Povirk:
Moc o tom nevím, ale zní to, že ovladač je správným řešením. Jde ale asi jen o to, že podpora ovladačů ve Wine není na fungování toho, co potřebuješ, dostatečně dobrá. Méně násilným řešením by tedy asi bylo vylepšit podporu ovladačů ve Wine, nejlépe do stavu, kdy stejný ovladač může fungovat na Windows a pod Wine (ale nevím, zda je to možné).
Dále osvětluje možná úskalí a uzavírá to slovy:
Protože si nemůžeš dovolit trávit spousty času nad vylepšováním podpory ovladačů ve Wine, bude pro podporu tvé aplikace nejlepším řešením si asi speciálně pro sebe upravit Wine.
Juan Lang má ale lepší nápad použitelný právě v situacích, kdy je při ruce zdrojový kód aplikace pro Windows:
Dříve se v podobných situacích navrhovalo napsat linuxovou aplikaci, která přímo komunikuje s ovladačem a poskytuje rozhraní přes soket, a následně používat sokety z programu pro Windows pro komunikaci se zařízením. To je obvykle dostatečně přímočaré a člověk se nemusí tak moc vrtat ve vnitřnostech Wine, aby to rozchodil.
Vincenta napadlo ještě elegantnější řešení pomocí winelib:
Winelib DLL poskytující API pro přímý přístup k zařízení (kterou můžete použít přímo z obyčejného programu pro Windows) může být snazší než oddělený proces, pokud je člověk ochoten upravovat aplikaci.
Oba návrhy připadají Pavlovi zajímavé. Ten na závěr doplnil výsledky své analýzy toho, co by bylo nutné udělat pro podporu ovladačů pro Windows a kde je ve zdrojových kódech ReactOS možné hledat inspiraci.
Na mailing listu Wine se objevil dotaz, zda se mají v překladech používat pro vyjádření výpustky tři oddělené tečky (...) nebo znak Unicode pro „trojtečku“ (…). Ukazuje se totiž, že se ve Wine používají tři tečky všude, až na češtinu a tradiční čínštinu, kde se používá Unicode trojtečka.
Dmitry Timoshkov říká, že by se mělo zůstat u používání obyčejných tří teček, a to kvůli kompatibilitě s bitmapovými fonty, fonty bez znaku výpustky a ANSI API (GetMenuItemInfoA/GetWindowTextA). Nakonec se ale ukazuje, že odpověď na tuto otázku už mají, a to v Microsoftu. Ten poskytuje volně ke stažení příručku pro překladatele do různých jazyků. Konkrétně u češtiny se píše:
Výpustka se běžné používá v anglickém i českém uživatelském rozhraní pro označení prvku (jako je tlačítko nebo položka v menu), který spouští dialogové okno, kde člověk zadává další údaje (jako Browse... = (+) Procházet...). Vzhledem k zachování kompatibility by v těchto případech neměl být používán znak výpustky (ALT+0133). Místo toho použijte tři tečky.
Drobností, která už proběhla i zprávičkami na AbcLinuxu, je úplná podpora aplikací pro Windows RT na Linuxu/Wine (ARM). Díky commitu zařazenému do Linuxu 3.11 se registr TPIDRURW považuje za TLS registr. Jeho hodnota je tedy ukládána/obnovována při přepínání kontextu mezi vlákny v systému.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
.
. Víc windows sw nepotřebuju 
.
Člověk by řekl, proč řeší tu ptákovinu s výpustkem. Problém je v odfláklých písmech od MS, které jsou sice Unicode, ale podporovaných znaků je v nich jak šafránu. V Tahomě, kterou používají jako výchozí pro UI sice výpůstek je, ale např. tam chybí jakákoliv šipka, což mě nedávno dost nakrklo při psaní jedné multiplatformní aplikace.
A když už jsem u těch písem, tak pro pobavení: Jejich Mapa znaků po tolika letech vývoje ani v nejnovějších Windows 8.1 neumí změnit velikost okna a má jakýsi prťavý fixní rozměr.
A když už jsem u těch písem, tak pro pobavení: Jejich Mapa znaků po tolika letech vývoje ani v nejnovějších Windows 8.1 neumí změnit velikost okna a má jakýsi prťavý fixní rozměr.Nejspíš z toho důvodu, že je to stále téměř stejná aplikace, která je nejspíš jen nově přeložená. Takových reliktů je ve Windows mnoho, hlavně v některých méně používaných nastaveních. Na druhou stranu budu raději mít cosi, co vypadá jako z časů Win3.1, pokud to bude fungovat a budu vědět, co kde nastavit, než mít nějaké "moderní" rohranií, co by se s každou verzí kompleně překopalo.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz