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.
u portálu s větší návštěvností (pěkně to popsané v starším Leošově článku) je výhodné držet si v cache věci, které jsem už načetl z databáze - ušetřím tím čas, který normálně strávím balením řádků z databáze (např.článků) do objektů. Do objektů je balím proto, že se s nimi potom dobře pracuje - třeba v šablonovacím systému. Při případné změně řádku v DB (editace článku) potom elegantně vysypu tu část cache, která je dotčená a běžím dál.Chápu, že pokud mám aplikaci v jednom procesu, který se dělí na více vláken, můžu cache jednoduše vysypat na jednom místě. Oproti tomu, pokud mám více procesů, musím všem procesům dát na vědomí, že se vysypat cache, což je velmi netriviální na implementaci (blbě se to programuje, blbě se to ladí, nevím kolik těch procesů je a tak). Více paralelních požadavků potřebuju, protože od určité návštěvnosti už jedna fronta požadavky obsluhovat stíhat nebude. --- Uvítám i myšlenky na efektivnější řešení
Chápu, že pokud mám aplikaci v jednom procesu, který se dělí na více vláken, můžu cache jednoduše vysypat na jednom místě. Oproti tomu, pokud mám více procesů, musím všem procesům dát na vědomí, že se vysypat cache, což je velmi netriviální na implementaci (blbě se to programuje, blbě se to ladí, nevím kolik těch procesů je a tak).Opravdu si myslíš, že vysypat cache sdílenou více vlákny je bez synchronizace košér? To je ovšem velmi naivní představa.
Více paralelních požadavků potřebuju, protože od určité návštěvnosti už jedna fronta požadavky obsluhovat stíhat nebude.Jedná blokující fronta ti nebude stačit velmi brzy. Od určité návštěvnosti budeš potřebovat více web serverů. Vertikálně škálovat nelze donekonečna.
Memcached jsem zkoumal, ale nevěřím tomu, že picklovat a unpicklovat složité Pythonové objekty bude stejně rychlé jako držet je v paměti.Memcached určitě nebude nic picklovat. To bude dělat Python a pokud myslíš, že pomalu, pak zkus jiný jazyk, nebo ukládej objekty jiným (lepším) způsobem
Opravdu si myslíš, že vysypat cache sdílenou více vlákny je bez synchronizace košér? To je ovšem velmi naivní představa.Když cache má GET, PUT i FLUSH implementované atomicky, tak by neměl být problém. Pletu se? Oproti tomu udělat synchronizaci v cache mezi více procesy je IMHO řádově složitější. Memcached by to teoreticky řešil.
Memcached určitě nebude nic picklovat. To bude dělat Python a pokud myslíš, že pomalu, pak zkus jiný jazyk, nebo ukládej objekty jiným (lepším) způsobem.Picklovat bude Python, ale nedokážu si představit, jestli režie picklování nebude větší než natahování z databáze. Objekty, které teď držím v cache jsou poměrně složité. Jediný způsob, jak to zjistit je to vyzkoušet. (zkusím a napíšu). Jestli existuje něco pohodlnějšího, tak se rád nechám poučit. Nenašel jsem zatím jazyk, který by mně osobně vyhovoval více než Python. A že jsem se snažil. (no flame please
Od určité návštěvnosti budeš potřebovat více web serverů. Vertikálně škálovat nelze donekonečna.Že časem budu potřebovat víc webserverů je mi už teď naprosto jasný, zatím naštěstí mám dost času, myslím, že ještě rok mi ještě bude stačit posilovat hardware
IMHO, lepšie ako zdielaná cache je prekopanie aplikácie, človek sa môže dostať do situácie, keď mu na CRUD jednotlivých entít bude postačovať jeden subdaemon a výsledok bude skladať druhým(tretím, ..) stupňom.
Tiskni
Sdílej: