Google oznámil, že Quick Share na Androidu funguje s AirDropem na iOS. Zatím na telefonech Pixel 10. Uživatelé tak mohou snadno přenášet soubory z telefonů s Androidem na iPhony a obráceně.
Byla vydána nová verze 8.5 (8.5.0) skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Přináší řadu novinek a vylepšení (URI Extension, Pipe Operator, Clone With, …). Vydána byla také příručka pro přechod z předchozích verzí.
Evropská komise zahájila tři vyšetřování týkající se cloudových platforem Amazon Web Services (AWS) a Microsoft Azure. Evropská exekutiva, která plní také funkci unijního antimonopolního orgánu, chce mimo jiné určit, zda jsou americké společnosti Microsoft a Amazon v cloudových službách takzvanými gatekeepery, tedy hráči, kteří významně ovlivňují provoz internetu a musí dle nařízení o digitálních trzích (DMA) na společném trhu
… více »Společnost Meta Platforms vyhrála ostře sledovaný spor o akvizici sítě pro sdílení fotografií Instagram a komunikační aplikace WhatsApp. Podle amerického soudu firma jejich převzetím neporušila antimonopolní zákon, protože si tak nemonopolizovala trh sociálních sítí. Žalobu na Metu podala před pěti lety americká Federální obchodní komise (FTC). FTC argumentovala, že Meta, tehdy známá jako Facebook, koupila tyto dvě společnosti v letech 2012 a 2014 proto, aby s nimi nemusela soutěžit.
Home Assistant včera představil svůj nejnovější oficiální hardware: Home Assistant Connect ZBT-2 pro připojení zařízení na sítích Zigbee nebo Thread.
Byla vydána verze 9.1 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 informačním videu.
Byl aktualizován seznam 500 nejvýkonnějších superpočítačů na světě TOP500. Nejvýkonnějším superpočítačem zůstává El Capitan od HPE (Cray) s výkonem 1,809 exaFLOPS. Druhý Frontier má výkon 1,353 exaFLOPS. Třetí Aurora má výkon 1,012 exaFLOPS. Nejvýkonnější superpočítač v Evropě JUPITER Booster s výkonem 1,000 exaFLOPS je na čtvrtém místě. Nejvýkonnější český superpočítač C24 klesl na 192. místo. Karolina, GPU partition klesla na 224. místo a Karolina, CPU partition na 450. místo. Další přehledy a statistiky na stránkách projektu.
Microsoft představil Azure Cobalt 200, tj. svůj vlastní SoC (System-on-Chip) postavený na ARM a optimalizovaný pro cloud.
Co způsobilo včerejší nejhorší výpadek Cloudflare od roku 2019? Nebyl to kybernetický útok. Vše začalo změnou oprávnění v jednom z databázových systémů a pokračovalo vygenerováním problém způsobujícího konfiguračního souboru a jeho distribucí na všechny počítače Cloudflare. Podrobně v příspěvku na blogu Cloudflare.
Byla vydána (Mastodon, 𝕏) první RC verze GIMPu 3.2. Přehled novinek v oznámení o vydání. Podrobně v souboru NEWS na GitLabu.
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: