Svobodný a otevřený multiplatformní editor EPUB souborů Sigil (Wikipedie, GitHub) byl vydán ve verzi 2.5.0. Stejně tak doprovodný vizuální EPUB XHTML editor PageEdit (GitHub).
Na základě národního atribučního procesu vláda České republiky označila Čínskou lidovou republiku za zodpovědnou za škodlivou kybernetickou kampaň proti jedné z neutajovaných komunikačních sítí Ministerstva zahraničních věcí ČR. Tato škodlivá aktivita, která trvala od roku 2022 a zasáhla instituci zařazenou na seznam české kritické infrastruktury, byla provedena kyberšpionážní skupinou APT31, veřejně spojovanou se zpravodajskou službou Ministerstvo státní bezpečnosti (MSS).
Google Chrome 137 byl prohlášen za stabilní. Nejnovější stabilní verze 137.0.7151.55 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 11 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Byl vydán AlmaLinux OS 10 s kódovým názvem Purple Lion. Podrobnosti v poznámkách k vydání. Na rozdíl od Red Hat Enterprise Linuxu 10 nadále podporuje x86-64-v2.
Byl vydán Mozilla Firefox 139.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 139 je již k dispozici také na Flathubu a Snapcraftu.
Byly publikovány výsledky průzkumu mezi uživateli Blenderu uskutečněného v říjnu 2024. Zúčastnilo se více než 7000 uživatelů. Téměř 93 % z nich například používá uživatelské rozhraní v angličtině.
Lukáš Růžička v článku RamaLama aneb vyháníme lamy na vlastní louku na MojeFedora.cz představuje open source nástroj RamaLama umožňující spouštět jazykové modely v izolovaných OCI kontejnerech, a to bezpečně, bez potřeby mít root přístup k počítači, s podporou GPU či CPU a bez zbytečných obtížností kolem.
Byl vydán Sublime Text 4 Build 4200. Sublime Text (Wikipedie) je proprietární multiplatformní editor textových souborů a zdrojových kódů. Ke stažení a k vyzkoušení je zdarma. Pro další používání je nutná licence v ceně 99 dolarů. Spolu se Sublime Merge je cena 168 dolarů.
Multiplatformní open source voxelový herní engine Luanti byl vydán ve verzi 5.12.0. Podrobný přehled novinek v changelogu. Původně se jedná o Minecraftem inspirovaný Minetest v říjnu loňského roku přejmenovaný na Luanti.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 25.5. Přehled novinek v Changelogu.
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: