T‑Mobile USA ve spolupráci se Starlinkem spustil službu T-Satellite. Uživatelé služby mohou v odlehlých oblastech bez mobilního signálu aktuálně využívat satelitní síť s více než 650 satelity pro posílání a příjem zpráv, sdílení polohy, posílání zpráv na 911 a příjem upozornění, posílání obrázků a krátkých hlasových zpráv pomocí aplikace Zprávy Google. V plánu jsou také satelitní data.
Společnost Proxmox Server Solutions stojící za virtualizační platformou Proxmox Virtual Environment věnovala 10 000 eur nadaci The Perl and Raku Foundation (TPRF).
Byla vydána nová verze 2.4.65 svobodného multiplatformního webového serveru Apache (httpd). Řešena je bezpečnostní chyba CVE-2025-54090.
Společnost Proton AG stojící za Proton Mailem a dalšími službami přidala do svého portfolia AI asistenta Lumo.
Amazon koupil společnost Bee zaměřenou na nositelnou osobní AI aktuálně nabízející náramek Pioneer (YouTube) s mikrofony zaznamenávající vše kolem [𝕏, LinkedIn].
Společnost Teufel nedávno představila svůj první open source Bluetooth reproduktor MYND.
Byla vydána verze 4.2 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.
Anton Carniaux, právní zástupce Microsoft France, pod přísahou: Microsoft nemůže garantovat, že data z EU nepředá do USA bez EU souhlasu, musí dodržovat americké zákony.
Byl vydán Mozilla Firefox 141.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Lokální AI umí uspořádat podobné panely do skupin. Firefox na Linuxu využívá méně paměti. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 141 je již k dispozici také na Flathubu a Snapcraftu.
NÚKIB upozorňuje na kritickou zranitelnost v SharePointu. Jedná se o kritickou zranitelnost typu RCE (remote code execution) – CVE-2025-53770, která umožňuje neautentizovaný vzdálený přístup a spuštění kódu, což může vést k úplnému převzetí kontroly nad serverem. Zranitelné verze jsou pouze on-premise verze a to konkrétně SharePoint Server 2016, 2019 a Subscription Edition. SharePoint Online (Microsoft 365) není touto zranitelností ohrožen.
Protože si spousta lidí stěžovala na pomalé načítání JXP Commanderu, upouštím od gtkmm a přepisuju ho do gtk. Nadále ale hodlám používat C++. Také budu používat vlákna, takže by výpis souborů a ostatní I/O operace neměly zdržovat načítání ani běh programu. Také veškeré stringy píšu v angličtině a používám na řetězce funkci (nebo je to makro?) gettext, takže by to pak mělo jít překládat i do jiných jazyků, jak je u většiny GNU programů zvykem. Také přemýšlím o použití cmake pro překlad programu, ale na to je zatím čas. Tak to je pro dnešek vše.
Tiskni
Sdílej:
Je pravda, že kompilovat C++ v gcc je vždycky zážitek.O RLY?
...kolikrát za den znovu spouštíte filemanager?...kdyz startuje pomalu, tak ani jednou! prikladem budiz docela pekny filemanager mucommander, jeden z mala, ktery je pro OS X, aniz bych musel nejak instalovat knihovny a kompilovat trebas mc nebo krusader. Je fajn, ale poooooooomaaaaluuuu to startuje, takze to radsi ani nespoustim...
...kolikrát za den znovu spouštíte filemanager?...kdyz startuje pomalu, tak ani jednou!
k
položek, můžeš obsah adresáře zobrazit v čase O(n + k*log(k))
, kde n
počet souborů v adresáři a k
je počet zobrazených řádků. Zbytek už můžeš třídit "na pozadí" v čase, kdy se uživatel teprve rozkoukává Myslim si, ze na to ale budes muset tech n polozek nejdriv setridit nebo sehnat alespon k-prvkovou podmnozinu polozek, ktere budou zarucene na zacatku setrideneho vypisu :)Třídit to celé opravdu nemusím: 1) budu mít haldu velikosti k (nazačátku zaplněnou třeba nekonečny) 2) vezmu prvek, porovnám s maximem na vrcholu, pokud je menší odeberu maximum, vložím prvek, obnovím haldu - to potrvá tedy nejvýše
O(log(k))
takže vybrání k nejmenších umím v O(n*log(k))
, potom už jenom setřídit těch k-prvků O(k*log(k))
, takže dohromady skutečně O((n + k) * log(k))
jxp-cmdr-0.0.1alpha1-src.tar.gz
. Fandim titerminate called after throwing an instance of 'Glib::ConvertError' Nespesne ukoncen (SIGABRT)
Také budu používat vlákna, takže by výpis souborů a ostatní I/O operace neměly zdržovat načítání ani běh programu.Vzpomeň na Johanku a její varování. S vlákny si může člověk pořádně nabít hubu. Zvlášť pokud se jedná o aplikaci s GUI. Nic proti vláknům, ale je to ošemetné - sice nevím, jak je na tom GTK+ z hlediska vláknové bezpečnosti, ale třeba pro javovský Swing platí docela přísná pravidla. Být tebou, dám si pozor
Vzpomeň na Johanku a její varování. S vlákny si může člověk pořádně nabít hubu. Zvlášť pokud se jedná o aplikaci s GUI. Nic proti vláknům, ale je to ošemetné - sice nevím, jak je na tom GTK+ z hlediska vláknové bezpečnosti, ale třeba pro javovský Swing platí docela přísná pravidla. Být tebou, dám si pozorPak ovšem toto nechápu. Z Lukova komentáře se mi zdá, že i když někdo práci s vlákny rozumí, dopadne to většinou špatně. Pokud tomu tak není, je ten komentář naprosto zbytečný a zavádějící...
Programovat nějaké paralelní procesy se dá i bez vláken, ale potom to vypadá... všelijak...On to zase až takový problém není. Pokud se používá framework s aspoň trochu rozumným mechanismem pro obsluhu událostí (např. Qt), tak si pak stačí jen hlídat, aby se běh nikde nezdržoval příliš dlouho. Každopádně je to mnohem jednodušší než se peklit se špatně fungujícím vláknovým kódem.
Nicméně vícevláknové aplikace existují a podle mých pozorování řada z nich funguje dobřeO tom není sporu. Velice ovšem záleží na tom, jaký charakter mají tyto aplikace. Pokud se sdílí jen málo prostředků a nepoužívají se žádné záludnější konstrukce, opravdu nebývají problémy. Nemohu ovšem nevzpomenout známý HTTP server Apache, který ve vláknové verzi (worker) funguje velice problematicky. Hlavním problémem jsou moduly, které většinou nejsou připraveny na multithreading - jenže Apache bez modulů (ve kterých je dnes víc než 90 % funkcionality) jaksi není to pravé ořechové. A něco podobného může nastat i zde (kromě problémů s GUI). Jakmile chceme do budoucna připustit používání pluginů, je potřeba myslet i na toto.
tím, že se tomu moduly zatím nestihli přizpůsobitMám silný pocit, že třeba PHP se ani moc přizpůsobit nesnaží. Přitom je to zrovna jeden z nejdůležitějších modulů.
Předpokládám přitom, že chování „threadoidního“ kódu v interpretujících virtuálních strojích se dá nějak rozumně srovnat do latě.Zase připomenu moji oblíbenou Javu