Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE.
Před 70 lety, 7. června 1954, ve věku 41 let, zemřel Alan Turing, britský matematik, logik, kryptoanalytik a zakladatel moderní informatiky.
NiceGUI umožňuje používat webový prohlížeč jako frontend pro kód v Pythonu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána ve verzi 2024.6. Z novinek lze vypíchnout lepší integraci LLM (OpenAI, Google AI, Ollama) nebo podporu Matter 1.3.
IKEA ve Spojeném království hledá zaměstnance do své nové pobočky. Do pobočky v počítačové hře Roblox. Nástupní mzda je 13,15 liber na hodinu.
Alyssa Rosenzweig se v příspěvku na svém blogu Vulkan 1.3 na M1 za 1 měsíc rozepsala o novém Vulkan 1.3 ovladači Honeykrisp pro Apple M1 splňujícím specifikaci Khronosu. Vychází z ovladače NVK pro GPU od Nvidie. V plánu je dále rozchodit DXVK a vkd3d-proton a tím pádem Direct3D, aby na Apple M1 s Asahi Linuxem běžely hry pro Microsoft Windows.
Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.90 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.90 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Byla vydána (Mastodon, 𝕏) nová verze 2024.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení.
Počítačová hra Tetris slaví 40 let. Alexej Pažitnov dokončil první hratelnou verzi 6. června 1984. Mezitím vznikla celá řada variant. Například Peklo nebo Nebe. Loni měl premiéru film Tetris.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.23.0. V přehledu novinek je vypíchnuta podpora dynamických USB zařízení nebo nové moduly openamp, tls a vfs.
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é.
Tiskni Sdílej: