Momo je fenka cavapoo, která svými náhodnými stisky kláves bezdrátové klávesnice vytváří jednoduché počítačové hry. Technicky to funguje tak, že Raspberry Pi s připojenou bluetooth klávesnicí posílá text do Claude Code, který pak v Godotu píše hry a sám je i testuje pomocí screenshotů a jednoduchých simulovaných vstupů. Za stisky kláves je Momo automaticky odměňována pamlsky. Klíčový je pro projekt prompt, který instruuje AI, aby i
… více »GNU awk (gawk), implementace specializovaného programovacího jazyka pro zpracování textu, byl vydán ve verzi 5.4.0. Jedná se o větší vydání po více než dvou letech. Mezi četnými změnami figuruje např. MinRX nově jako výchozí implementace pro regulární výrazy.
Internetový prohlížeč Ladybird ohlásil tranzici z programovacího jazyka C++ do Rustu. Přechod bude probíhat postupně a nové komponenty budou dočasně koexistovat se stávajícím C++ kódem. Pro urychlení práce bude použita umělá inteligence, při portování první komponenty prohlížeče, JavaScriptového enginu LibJS, bylo během dvou týdnů pomocí nástrojů Claude Code a Codex vygenerováno kolem 25 000 řádků kódu. Nejedná se o čistě autonomní vývoj pomocí agentů.
Byl vydán Mozilla Firefox 148.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Nově lze snadno povolit nebo zakázat jednotlivé AI funkce. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 148 bude brzy k dispozici také na Flathubu a Snapcraftu.
Byla vydána nová verze 22.1.0, tj. první stabilní verze z nové řady 22.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools a Libc++.
X86CSS je experimentální webový emulátor instrukční sady x86 napsaný výhradně v CSS, tedy bez JavaScriptu nebo dalších dynamických prvků. Stránka 'spouští' assemblerovový program mikroprocesoru 8086 a názorně tak demonstruje, že i prosté CSS může fungovat jako Turingovsky kompletní jazyk. Zdrojový kód projektu je na GitHubu.
Po šesti letech byla vydána nová verze 1.3 webového rozhraní ke gitovým repozitářům CGit.
Byla vydána nová verze 6.1 linuxové distribuce Lakka (Wikipedie), jež umožňuje transformovat podporované počítače v herní konzole. Nejnovější Lakka přichází s RetroArchem 1.22.2.
Matematický software GNU Octave byl vydán ve verzi 11.1.0. Podrobnosti v poznámkách k vydání. Vedle menších změn rozhraní jsou jako obvykle zahrnuta také výkonnostní vylepšení a zlepšení kompatibility s Matlabem.
Weston, referenční implementace kompozitoru pro Wayland, byl vydán ve verzi 15.0.0. Přehled novinek v příspěvku na blogu společnosti Collabora. Vypíchnout lze Lua shell umožňující psát správu oken v jazyce Lua.
Krátký zápisek. Před pár dny jsem u kontejneru na elektroodpad u metra našel vrak počítače, ze kterého jsem vyndal pevný disk a čtečku paměťových karet. Ale co jsem našel na tom disku, to bylo vcelku zajímavé.
Chvíli mi trvalo, než jsem ten disk oživil (musel jsem sehnat redukci na napájení SATA -> Molex, protože ten disk je ještě IDE). Sice ne, že by tam byly nějaké tajné materiály Islámského Státu, nicméně ten disk evidentně patřil majiteli jisté restaurace zde v Praze, která mimochodem v roce 2012 zkrachovala. Na tom disku byly jídelní lístky, nějaké faktury, ale i životopisy zaměstnanců, a taky fotky nějaké rodiny a přihlašovací certifikáty (byť dávno propadlé) do internetbankingu KB.
Nevím, ale přijde mi docela nezodpovědnost, nebo blbost, nebo obojí. Řekl bych ale, že minimálně ty životopisy by mohly být žalovatelné, protože zákon o ochraně osobních údajů. Já se v tom šťourat nebudu, disk jsem smazal (přepsal nulami), ale někdo jiný by mohl. Přitom by stačilo ten disk jen normálně zformátovat, a málokterý nálezce by se tam pokoušel hledat nějaké smazané soubory.
Tohle byl už druhý disk, který jsem takhle našel, nicméně na tom předchozím opravdu nic zajímavého nebylo. Tam byl nainstalovaný Linux Mint (na tom co jsem našel teď byly WinXP), a v prohlížeči v historii jen pár dětských webů.
A co vy? Jak se zbavujete starých disků, abyste předešli úniku dat?
Tiskni
Sdílej:
Rozšoubuji (asi do 5 minut), vyndaný disk buď rozkřápnu (skleněné) nebo kovové na betonu pomlátím kladivem. Zkrátka nevlastníme v Česku jaderné zbraně. Top Secret - Cosmic Top Secret. 
Disky z pole jdou na reklamaci rovnou, protože tam se opravdu nebojím, že by to někdo složil (a né, opravdu RAID1 nepoužíváme).Složil asi ne, ale krátké soubory, ve kterých jsou klíče/hesla by tam mohly být celé.
Pokud víš, kam firma XY vyhazuje disky a automatizuješ si to, tak se ti dříve či později „poštěstí“, aniž by tě to stálo nějak moc práce.
Mně tohle prostě přijde paradoxní – v souvislosti s tím, na jak často i hodně nepravděpodobná rizika se firmy připravují a stresují kvůli nim – a pak si nepohlídají takhle primitivní únik.
BTW: jinak se tomu taky říká trashing – prohrabávání se v cizích odpadcích. Dá se toho tak získat a pak poskládat dohromady opravdu hodně. Ne, že bych se zkoušel hrabat v cizí popelnici, ale zkoušel jsem víc přemýšlet o tom, co vyhazuji a jakou informaci to nese… a pak jsem si pořídil skartovačku.
Myslím, že RAID a jeho stripe size bude ten problém. Na každém daném disku je vždy třeba 128kB souvislých dat.Přesně tak. Do toho stačí započítat, že FS data ukládá od začátku "sektoru" a třeba takové klíče uložené v PEM formátu mají jasně a snadno identifikovatelnou hlavičku. Vzhledem k tomu, jak snadné je disk aspoň jednou přepsat, což odfiltruje snahy 99.9% šmoulů, co se hrabou v elektroodpadu, nevidím jediný důvod to neudělat.
Nejlepším řešením je samozřejmě šifrovat, ale ten overhead se nemusí vůbec vyplatit.S ohledem na podporu AES-NI v dnešních procesorech ten overhead nepředstavuje větší problém. Rozhodně ne u klasických disků.
Nějak si ani nedokážu představit, že tam člověk našel něco kloudnýho.Zkoušel jsi někdy na takový disk poslat photorec nebo podobný nástroj? Ty mezivrstvy typicky zachovávají bloky a snaží se eliminovat jakékoliv transformace dat. Je velmi pravděpodobné, že souvislý blok dat ve VM bude souvislým blokem dat i na fyzickém disku. Nejspíš budou jen zpřeházené větší kusy, jak si VM alokovalo další a další místo pro virtuální disk, ale to je docela malá komplikace, pokud obnovovací nástroj jde rovnou po datech, hledá hlavičky souborů a neřeší filesystém.
strings.
Tohle jsem řešil už před lety v souvislosti s reklamacemi disků. Obchodníci nejsou schopní ti zaručit, že vadný disk zničí, aby z něj nikdo nic nepřečetl. Je to jeden z mnoha důvodů, proč šifrovat. Když šifrovaný disk odejde, není velký problém ho reklamovat, rozebrat na součástky nebo darovat… Fyzickou likvidaci bych zvažoval jen v případě, že by disk obsahoval něco opravdu hodně citlivého, co by mělo dopad, i za X let, kdy ta šifra bude třeba prolomená.
Těmi „desítkami milionů“ to docela shazuje, ale jinak to může sloužit jako dobré varování všem, kdo ledabyle nakládají s vlastními (nebo ještě hůř, s cizími) daty.
Řekl bych ale, že minimálně ty životopisy by mohly být žalovatelné, protože zákon o ochraně osobních údajů.Jo, ÚOOÚ by k tomu pravděpodobně měl co říct...
A co vy? Jak se zbavujete starých disků, abyste předešli úniku dat?V práci je přepisujeme nulami nebo urandom, když jdou na reklamaci kvůli vadným sektorům nebo jinému problému, kde ten disk ještě nějak funguje. Ostatní disky jdou do velké krabice a pak pod vrtačku. Jako ochrana před popeláři to stačí a state-level špiony neřešíme.
A co vy? Jak se zbavujete starých disků, abyste předešli úniku dat?Občas nějaké rozebírám na magnety a úmyslně při tom pomatlám a poškrábu plotny.
dd if=/dev/urandom of=/dev/sdX
A pak tam přes gParted udělám prázdnou FAT32 a ven s ním. Většinou tam by předtím jiný fs i rozdělení disku, takže pravděpodobnost obnovy dat se blíží nule.
cat /dev/urandom > /dev/sdX?
IMHO je jádro tak nějak asi ví co dělá a je podstatné to jádro neobtěžovat zbytečně malými (a tedy početnými) požadavky, když můžu použít i velké.Já bych byl taky pro, ale tady to bylo obráceně - chtěl jsem bloky 4MB, průměrná velikost I/O požadavku na ten disk byla asi 1kB. Testoval jsem Ceph a RBD, takže čtení bloků o velikosti pod 4MB může vést na nadbytečné I/O operace. To dd jelo sekvenčeně (jak jinak), takže bych tam viděl větší prostor pro slučování jednotlivých I/O requestů, než kolik jádro dělalo.
Respektive z pohledu dd možná joGNU dd dělá read() s velikostí odpovídající zadané blocksize a jádro mu může dát libovolně méně. To se stane když zařízení nestíhá nebo když přijde signál. Pikantní to je když se někdo snaží odměřovat množství dat tímto způsobem a pak mu to zfailí. Řešení? iflag=fullblock (a nebo nepoužívat dd)
ale jádro si z disku četlo v tak malých blocích, jak se mu zachtěloMně nešlo o to v jak malých blocích se bude číst ze zařízení (tam se toho stejně zhostí readahead) ale že když děláš read(512), tak pro přepsání terabajtu dat musíš udělat dvě miliardy syscallů.
To se stane když zařízení nestíhá nebo když přijde signál. Pikantní to je když se někdo snaží odměřovat množství dat tímto způsobem a pak mu to zfailí. Řešení? iflag=fullblockVida, to bych čekal, že bude zapnuté automaticky...
Mně nešlo o to v jak malých blocích se bude číst ze zařízení (tam se toho stejně zhostí readahead) ale že když děláš read(512), tak...Což to jo, to mi bylo jasné.