Po 8. květnu 2026 už na Instagramu nebudou podporované zprávy opatřené koncovým šifrováním. V chatech, kterých se bude změna týkat, se objeví pokyny o tom, jak si média nebo zprávy z nich stáhnout, pokud si je chcete ponechat.
V lednu byla ve veřejné betě obnovena sociální síť Digg (Wikipedie). Dnes bylo oznámeno její ukončení (Hard Reset). Společnost Digg propouští velkou část týmu a přiznává, že se nepodařilo najít správné místo na trhu. Důvody jsou masivní problém s boty a silná konkurence. Společnost Digg nekončí, malý tým pokračuje v práci na zcela novém přístupu. Cílem je vybudovat platformu, kde lze důvěřovat obsahu i lidem za ním. Od dubna se do Diggu na plný úvazek vrací Kevin Rose, zakladatel Diggu z roku 2004.
MALUS je kontroverzní proprietarní nástroj, který svým zákazníkům umožňuje nechat AI, která dle tvrzení provozovatelů nikdy neviděla původní zdrojový kód, analyzovat dokumentaci, API a veřejná rozhraní jakéhokoliv open-source projektu a následně úplně od píky vygenerovat funkčně ekvivalentní software, ovšem pod libovolnou licencí.
Příspěvek na blogu Ubuntu upozorňuje na několik zranitelností v rozšíření Linuxu o mandatorní řízení přístupu AppArmor. Společně jsou označovány jako CrackArmor. Objevila je společnost Qualys (technické detaily). Neprivilegovaný lokální uživatel se může stát rootem. Chyba existuje od roku 2017. Doporučuje se okamžitá aktualizace. Problém se týká Ubuntu, Debianu nebo SUSE. Red Hat nebo Fedora pro mandatorní řízení přístupu používají SELinux.
Byla vydána nová verze 19 integrovaného vývojového prostředí (IDE) Qt Creator. Podrobný přehled novinek v changelogu.
Bitwig Studio (Wikipedie) bylo vydáno ve verzi 6. Jedná se o proprietární multiplatformní (macOS, Windows, Linux) digitální pracovní stanici pro práci s audiem (DAW).
Společnost Igalia představila novou linuxovou distribuci (framework) s názvem Moonforge. Jedná se o distribuci určenou pro vestavěné systémy. Vychází z projektů Yocto a OpenEmbedded.
Google Chrome 146 byl prohlášen za stabilní. Nejnovější stabilní verze 146.0.7680.71 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 29 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
D7VK byl vydán ve verzi 1.5. Jedná se o fork DXVK implementující překlad volání Direct3D 3 (novinka), 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Bylo vydáno Eclipse IDE 2026-03 aneb Eclipse 4.39. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Pokračování 2 předešlých zápisků.
Ha! Tak se mi podařilo zfunkčnit Gtk# (2.12) pro Windows x64 s 64 bitovými Gtk knihovnami. Tady je poněkud těžkopádný postup, jak jsem to udělal.
Vynechám omyly, takže jen postup jak toho docílit (Rozhodl jsem se nekompilovat buildsystémem, protože chce cygwin): Stáhnout zdrojáky GtkSharp ze SVN. Stáhnout x86_64 balíček gtk-sharp z repozitářů ArchLinuxu (či jiné distribuce, dokonce může být i 32bit, protože .NET knihovny nejsou vázány architekturou). Z balíčků ArchLinuxu "ukradneme" soubory atk-sharp.dll, gdk-sharp.dll, glib-sharp.dll, pango-sharp.dll, gtk-sharp.dll a gtk-dotnet.dll. Dále ukradneme gapi_codegen.exe, atk-api.xml, gdk-api.xml, glib-api.xml, gtk-api.xml a pango-api.xml. Xml soubory umístíme do složek atk, gdk, glib, gtk a pango ve zdrojácích ze svn (ušetří nám to použití parseru). Dále do adresářové struktury zkopčíme mnou vytvořené makefile soubory nevyžadující cygwin ani msys. Pak v kořenovém adresáři zdrojáků spustíme make, které nám (s pomocí mingw-w64) vytvoří *glue*.dll soubory, na kterých jsou ty .NET knihovny závislé (jsou tam nějaké wrapper fce pro gtk).
Vytvoříme nový projekt ve Visual C# Express (či Standard, Professional, podle toho, co máte). Do "binary output directory" zkopčíme *-sharp.dll a *glue*.dll soubory, klikneme pravým na projekt, vybereme "Add reference", záložka browse a vybereme (JEN) *-sharp.dll soubory (je jich 5). Do zdrojáku programu pak napíšeme následující kód, zkompilujeme a je to
using System;
using Gtk;
namespace GtkSharpTest2
{
class Program
{
static void Main(string[] args)
{
Application.Init();
Button btn = new Button("Hello world");
btn.Clicked += new EventHandler(hello);
Window window = new Window("Hello world");
window.DeleteEvent += delete_event;
window.Add(btn);
window.ShowAll();
Application.Run();
}
static void delete_event(object obj, DeleteEventArgs args)
{
Application.Quit();
}
static void hello(object obj, EventArgs args)
{
Console.WriteLine("Hello world");
}
}
}
Binárky (*glue*.dll) a vlastní Makefile zveřejním na požádání (zdarma). Teď ještě Cairo pro C# (asi také z balíčku ArchLinuxu) - snad nebude chtít žádné glue soubory
a nějaké ty závislosti pro Banshee a pak samotné banshee (to jsem teda zvědavý).
Binárky zde. O makefile musí někdo požádat
Tak jsem ještě zkompiloval libglade (+ libxml2 a iconv, na kterých závisí), gtksharpglue-2.dll a opět ukradl glade-sharp.dll z toho balíčku
Někdy zítra to celé včetně 64bit gtk zabalím a zveřejním, ať stačí stáhnout all-in-one balíček a né 20 věcí zvlášť.
Ouvej. O svém výtvoru jsem informoval vývojáře na mailing listu Gtk# a tam mi řekli, že není dobré vzít knihovny z linuxu, protože prý jsou vytvořené s tím, že sizeof(long) = 8 a právě proto, že tam je ten parser, že to správně převede podle platformy. Takže sice mi to funguje, ale jen do té doby, než ta .NET knihovna zavolá funkci, která bere long. Rozhodl jsem se teda rekompilovat i .NET knihovny. Zatím mám glib-sharp, Mono.Cairo (na to jsem před tím zapomněl, může to vyžadovat pango-sharp při určitých volání) a pango-sharp. Zbytek po pauze a pak slíbený upload.
Už jen gtkdotnet.dll a cairo-sharp.dll. Slíbený upload udělám asi až zítra, dneska to už nestíhám, musím také dělat něco jiného než sedět u PC (např. koukat na telku
).
Hmm. Tak teď na tom mailing listu z někoho vylezlo, že při kompilaci toho jejich generátoru musím definovat WIN64LONG, jinak budu přesně tam, kde jsem byl s těma knihovnama z linuxu. Naneštěstí to pak při kompilaci gtk-sharp.dll dělá neplechu a mlátí se tam int s longem v jednom zdrojáku. Nahlásil jsem to a snad brzy to bude spraveno. Do té doby asi nemá cenu uploadovat ty knihovny, protože to kdykoliv může upsnout.
Pánové z týmu Gtk# si špatně vyložili typ gsize a na windows x64 jej interpretují jako long a jen náhodou jsem na něj narazil při mých hrátkách. Projeví se např. při použití gtk_text_buffer_serialize a následném volání callback funkce GtkTextBufferSerializeFunc, která 5 parametr očekává gsize, ale pánové od Gtk# se rozhodli tam strčit UIntPtr na Win32 (stejná velikost, tak budiž a berme to jako ok), ale uint na Win64, což může mít kritické následky. Určitě tam toho bude víc. Problém jsem ohlásil na mailing listu a bugzille. Líp jsem to popsat nedokázal.

Snad předposlední update (poslední bude, až to uploadnu .. a nebo možná vytvořím nový zápis, uvidím). Zmíněný bug byl celkem rychle opraven v SVN trunku a knihovny jsem zkompiloval. Ještě test a zítra to snad už uploadnu, pokud zase něco nenajdu
Stručné info a odkaz ke stáhnutí: http://jarduvblocek.blogspot.com/2008/09/gtk-for-windows-x64.html.
Tiskni
Sdílej: