Společnost Eclypsium se na svém blogu rozepsala o bezpečnostním problému počítačů Framework. Jedná se o zranitelnost v UEFI umožňující útočníkům obejít Secure Boot.
Editor kódů Zed (Wikipedie) po macOS a Linuxu s verzí 0.208.4 už běží také ve Windows.
Apple dnes představil 14palcový MacBook Pro, iPad Pro a Apple Vision Pro s novým čipem M5.
Debian pro mobilní zařízení Mobian (Wikipedie) byl vydán ve verzi 13 Trixie. Nová stabilní verze je k dispozici pro PINE64 PinePhone, PinePhone Pro a PineTab, Purism Librem 5, Google Pixel 3a a 3a XL, OnePlus 6 a 6T a Xiaomi Pocophone F1.
Operátor O2 představil tarif Datamanie 1200 GB . Nový tarif přináší 1200 GB dat s neomezenou 5G rychlostí, a také možnost neomezeného volání do všech sítí za 15 Kč na den. Při roční variantě předplatného zákazníci získají po provedení jednorázové platby celou porci dat najednou a mohou je bezstarostně čerpat kdykoli během roku. Do 13. listopadu jej O2 nabízí za zvýhodněných 2 988 Kč. Při průměrné spotřebě tak 100 GB dat vychází na 249 Kč měsíčně.
Byly publikovány informace o útoku na zařízení s Androidem pojmenovaném Pixnapping Attack (CVE-2025-48561). Aplikace může číst citlivá data zobrazovaná jinou aplikací. V demonstračním videu aplikace čte 2FA kódy z Google Authenticatoru.
Free Software Foundation (FSF) spustila projekt Librephone, jehož cílem je vytvoření svobodného operačního systému pro mobilní telefony. Bez binárních blobů.
Byla vydána verze 7 s kódovým název Gigi linuxové distribuce LMDE (Linux Mint Debian Edition). Podrobnosti v poznámkách k vydání. Linux Mint vychází z Ubuntu. LMDE je postaveno na Debianu.
Byl vydán Mozilla Firefox 144.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Vypíchnout lze lepší správu profilů. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 144 bude brzy k dispozici také na Flathubu a Snapcraftu.
Discord potvrdil únik osobních údajů přibližně 70 000 uživatelů. Incident se týká uživatelů po celém světě, především těch, kteří v rámci ověřování svého věku nahráli do aplikace doklad totožnosti. Únik informací se netýkal systémů samotné platformy, ale došlo k němu přes kompromitovaný účet pracovníka zákaznické podpory u externího poskytovatele služeb.
Tohle je moje odpověď na mail kamarádovi ohledně možností Pythonu na webu, třeba bude někoho zajímat taky, třeba někdo něco doplní.
CGI je pro web vcelku použitelné. Nevím, co to udělá s výkonem serveru, pokud bys měl hodně přístupů na ten web. Malé weby jako http://fotosoutez.cestovatel.cz/, http://promitani.cestovatel.cz/, http://www.koren.cz/kaplanovi běží jako CGI aplikace.
Výhoda CGI je v tom, že nemusím nasazovat žádnou sofistikovaný udělátor. Prostě rychle udělám skript, nastavím v Apachi ExecCGI, případně nějaký Rewrite či ScriptAlias a běží to. CGI v Pythonu (a obecně jakémkoliv skriptovacím jazyce) má nevýhodu, že se pro každý požadavek musí vytvořit nový proces a interpreter, zkompilovat skript do bytekódu a začít ho provádět. To může občas chvíli trvat.
mod_python se to snaží vylepšit tím, že zapouzdří interpreter Pythonu do Apache. Pro jednoduché věci je to výhodné - vypadne režie nutná ke spuštění interpreteru, skript se kompiluje jenom jednou a pak se vždy vykonává. Navíc máš dokonce přístup k vnitřním proměnným Apache (což se taky občas může hodit). Největší nevýhodou mod_python vidím v tom, že aplikace běží pod oprávněním Apache, což není na produkčním serveru úplně ideální.
Pro mod_python existují různé zajímavé rozšíření (třeba publisher, který mapuje části cesty z URI na volání funkční z modulů, PythonServerPages handler - které umožňuje zapisovat do stránky kód v Pythonu podobně jako PHP a asi i spousta dalších.)
Myslím, že mod_python je vhodný zejména na drobné věci, na které neexistuje v Apachi modul - vhodné využití je třeba naprogramování autentizace proti SQL databázi, složitější přepisovací pravidla, na která mod_rewrite nestačí, nebo interakce s aplikačním serverem.
Pro reálné nasazení nám to v práci dělalo divné věci, všechno to běží uvnitř apache, různě se tam recyklovaly interpretery, takže se to hůř ladilo. Můj názor je, že mod_python je vhodný, pokud se kód vejde do cca 2 stránek na obrazovce. Tam je ještě možné uhlídat případné chyby a nenadělám moc velké škody.
FastCGI je IMHO slepá větev. (asi není!, viz diskuse níže) Místo obyčejného CGI skriptu se spáchá FastCGI skript, který běží dlouho a obsluhuje větší množství požadavků, které postupné dostává. Ušetří se opakované vytváření procesu, zavádění interpreteru a kompilace kódu. Výhodou je možnost použití s původním kódem pro CGI.
Nejvíce se mi teď líbí aplikační servery (možná existuje i lepší název, ale nevím o něm). Nejstarší je asi můj oblíbený Webware for Python, teď zrovna letí Django, TurboGears a CherryPy. (Můj oblíbený Cestovatel je postaven právě na W4PY.)
Co to je? Aplikační server je proces, který běží trvale (tedy měl by běžet ), přijímá požadavky a odpovídá na ně. Kde je rozdíl mezi aplikačním server a webovým serverem? Aplikační server nemusí umět a často ani neumí HTTP, ale má zase jiné přednosti.
Existuje spousta dalších přístupů pro řešení webu v Pythonu, třeba Zope, Maki, WSGI a spousta dalších. S těmi jsem ale nepřišel do styku na dost dlouhou dobu.
Pro jednoduché aplikace, kdy se nezpracovávají velké objemy dat z databáze používám CGI skripty, pro aplikace, kde se stránka sestavuje z mnoha tabulek z databáze používám W4PY a důsledně cachuju (v době, když jsem začínal programovat nic jiného nebylo). Pro generování stránek používám Cheetah, ať už v CGI, tak i W4PY.
Líbí se mi Django, ale ještě jsem nenašel dost času ho prozkoumat, přecejen mne weby neživí.
Tiskni
Sdílej:
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.