#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
Společnost Volla Systeme stojící za telefony Volla spustila na Kickstarteru kampaň na podporu tabletu Volla Tablet s Volla OS nebo Ubuntu Touch.
Společnost Boston Dynamics oznámila, že humanoidní hydraulický robot HD Atlas šel do důchodu (YouTube). Nastupuje nová vylepšená elektrická varianta (YouTube).
Desktopové prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklé sloučením projektů Razor-qt a LXDE bylo vydáno ve verzi 2.0.0. Přehled novinek v poznámkách k vydání.
Nejvyšší soud podpořil novináře Českého rozhlasu. Nařídil otevřít spor o uchovávání údajů o komunikaci (data retention). Uvedl, že stát odpovídá za porušení práva EU, pokud neprovede řádnou transpozici příslušné směrnice do vnitrostátního práva.
Minulý týden proběhl u CZ.NIC veřejný test aukcí domén. Včera bylo publikováno vyhodnocení a hlavní výstupy tohoto testu.
Byla vydána nová verze 3.5.0 svobodné implementace protokolu RDP (Remote Desktop Protocol) a RDP klienta FreeRDP. Přehled novinek v ChangeLogu. Opraveno bylo 6 bezpečnostních chyb (CVE-2024-32039, CVE-2024-32040, CVE-2024-32041, CVE-2024-32458, CVE-2024-32459 a CVE-2024-32460).
Google Chrome 124 byl prohlášen za stabilní. Nejnovější stabilní verze 124.0.6367.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 22 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Byla vydána nová verze 9.3 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Novinkou je vlastní repozitář DietPi APT.
Byl vydán Mozilla Firefox 125.0.1, první verze z nové řady 125. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Vypíchnout lze podporu kodeku AV1 v Encrypted Media Extensions (EME). Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 125.0.1 je již k dispozici také na Flathubu a Snapcraftu.
Další důležité parametry jsou bs (určuje velikost vstupních i výstupních bloků, výchozí je 512 bytů)Co to jsou ty bloky a jak mám poznat jakou velikost mám zadat? 2)
Argument sync parametru conv zajistí doplnění každého vstupního bloku na velikost vstupního bufferu (zadaného v tomto případě přes parametr bs)Tuhle větu nechápu vůbec. K čemu to slouží? 3)
Argument notrunc téhož parametru zabraňuje zkrácení případného existujícího výstupního souboru CD.iso (tj. pokud CD.iso již existuje, bude se obsah nahrazovat postupně od začátku přepisováním souboru)Jakože když už soubor existuje a já DD spustím znovu bez notrunc, tak budu mít hned dvě image najednou spojený v jednom souboru? Ta první věta zní děsně, moc ji nechápu. 4)
Argument noerror zajistí pokračování i v případě chybJaký chyby jsou myšleny? Já si dovedu představit jen chybu, když se mi fleška na kterou kopíruju image zaplní. 5) Jak image komprimovat? Na internetu jsem si sice našel příklad a asi bych si dokázal upravit cesty ( asi takhle? dd if=/dev/sda | gzip > /mnt/sdb1/obraz.gz) ale nejsem si příliš jistej. Hlavně nevím jestli mám k tomu použít ty ostatní parametry (bs, noerror apod.) a jak a proč. 6) A jak tu image zase BEZPEČNĚ vrátit? A opět použít nějaký parametry? Díky všem za rady. Nerad bych totiž vytvořil zálohu která bude vadná, nepůjde vrátit, nebo bude nefunkční.
Řešení dotazu:
# vytvoreni zalohy dd if=/dev/sdX conv=sync,noerror bs=64K | gzip -c > /path/to/backup.img.gz #obnova zalohy gunzip -c /path/to/backup.img.gz | dd of=/dev/sdXcesta "/path/to/" musi samozrejme smerovat na jiny, nez ten zalohovany/obnovovany disk...
Co to jsou ty bloky a jak mám poznat jakou velikost mám zadat?dd prečíta blok zo vstupu a zapíše blok na výstup. A potom ďalší. A ďalší. Historicky niektoré médiá pracovali efektívnejšie ak dd použilo veľkosť bloku, ktorý sedel s veľkosťou alokačnej jednotky súborového systému, či veľkosťou sektoru, clustra, čojaviemčoho. V dnešnej dobe to moc nemá význam riešiť. Hlavne ak sa bavíme o diskoch.
Argument notrunc téhož parametru zabraňuje zkrácení případného existujícího výstupního souboruKeď sa pustíš zapisovať do nejakého súboru, tak prvá operácia, ktorá sa urobí je open(). Ak ten súbor už existuje, tak open() môže zafungovať tak, že pozíciu, na ktorú sa bude zapisovať, nastaví na začiatok (pozíciu 0) a najbližšie write() bude zapisovať na začiatok súboru. Ak žiaden write neurobíš, tak súbor ostane s veľkosťou 0B. Zvyšok súboru sa zahodí. Po anglicky "truncate" - "odrezať zvyšok, skrátiť". Druhá varianta, je že sa po open() nastaví pozícia na koniec súboru a teda nasledujúci write() bude pridávať na koniec existujúceho súboru. Po anglicky "append".
Jaký chyby jsou myšleny?Akékoľvek, ktoré môžu nastať pri čítaní alebo zápise. Od chýb média, cez nedostatok priestoru na zápis, atď. Čítať môžeš nielen z bežného súboru, ale aj z rúry, sériového portu atď atď. To isté pre zápis.
Jak image komprimovat? Na internetu jsem si sice našel příklad a asi bych si dokázal upravit cesty ( asi takhle? dd if=/dev/sda | gzip > /mnt/sdb1/obraz.gz)Buď najprv urobíš kópiu a potom ju skomprimuješ,
dd if=vstupny_subor of=vystupny_subor gzip vystupny_suboralebo to budeš robiť v jednom kroku, tak ako si napísal. V tom prípade ale musíš gzip-u povedať, že komprimuje to, čo dostane na štandardný vstup. To sa robí parametrom -c
dd if=/dev/sda | gzip -c > /mnt/sdb1/obraz.gz
A jak tu image zase BEZPEČNĚ vrátit?
gunzip zaloha.gz dd if=zaloha of=vystupresp.
gunzip -c zaloha.gz | dd of=vystup
A opět použít nějaký parametry?Pre dd potrebuješ len if=, of= . Pre gzip/gunzip môžeš chcieť -c (spracovanie štandardného vstupu/výstupu miesto nejakého súboru) a prípadne úroveň kompresie. Tá sa udáva ako číslo. -9 je najväčšia, ale aj najpomalšia. Opakom je -1, čo je najrýchlejšia, ale menej účinná. Komprimovať s -9 to čo už je komprimované (napr. video) je strata času. Každopádne odporúčam najprv si to nacvičiť na niečom malom. Tiež môžeš zvážiť použitie nejakého konkrétneho backupovacieho softu. Ten sa môže vyhnúť zbytočnému zálohovaniu nevyužitého priestoru na disku.
Jaký chyby jsou myšleny? Já si dovedu představit jen chybu, když se mi fleška na kterou kopíruju image zaplní.Vadné sektory na disku. V tom případě je ale vhodnější použít specializovaný nástroj na obnovu dat, například ddrescue.
6) A jak tu image zase BEZPEČNĚ vrátit? A opět použít nějaký parametry?Prohodíš vstupní a výstupní soubor a pokud jsi komprimoval, přidáš parametr -d (jako decompress).
třeba na zkopírování 1MB dat od adresy XXXTak schválně, chyták: jak bys zkopíroval pomocí dd z coreutils 100 M(i)B od adresy 0? Hint: dd.c:1090
od Petr Šobáň >> 3.) Prostě soubor se přepisuje od začátku, a pokud je kratší než původní uložený tak se neskrátí a na konci zůstanou původní data.Díky moc, konečně jsem to pochopil. Všude to píšou komplikovaně a a tohle je krásně srozumitelný. Díky. Takže ho můžu s klidým svědomím vynechat.
od Petr Šobáň >> 1.) není to důležitý parametr - když to neurčíš poběží to pomalej, ale nic se nestane.A pokud ho chci určit jak ho určím optimálně?
od rastos >> alebo to budeš robiť v jednom kroku, tak ako si napísal. V tom prípade ale musíš gzip-u povedať, že komprimuje to, čo dostane na štandardný vstup. To sa robí parametrom -cJasně že to chci v jednom kroku, tolik místa na flešce nemám. Takže díky, díky, díky. O tom parametru -c jsem netušil a zkoušel jsem to bez toho.
od rastos >> a prípadne úroveň kompresie. Tá sa udáva ako číslo. -9 je najväčšiaZase podstatná věc, díky. A já se divil, že mi nestačilo místo na flešce (mimochodem1 - jaká je nastavená výchozí komprese?)
od rastos >> Akékoľvek, ktoré môžu nastať pri čítaní alebo zápise. Od chýb média, cez nedostatok priestoru na zápis, atď.Dobře chápu. Takže když to mám bez paramteru noerror a dojde k chybě tak se operace zastaví a zbyde mi třeba jen půlka image? Vypíše to nějaký chybový hlášení? A když to mám s parametrem noerror, tak se stane co? Jakože čte, čte, čte, najedou se objevý vadná oblast tak co? Tam kde to nemůže přecíst tak to tu část image vyplní nulama, nebo to jen ignoruje a čte další čitelnou oblast? Opět, dostal bych nějaký chybový hlášení s tímto parametrem? (mimochodem2 - Co se stane když se mi bude vytvářet image větší než 4GB na flešku s FAT32?) Měl bych i spoustu dalších otázek ohledně zobrazení stavu v %, nebo vyčištění disku (předopkládám, že se do image nahrajou z disku i smazaný soubory a image tak neůměrně naboptná), ale musím nejdřív strávit tenhle základ. Ale kdyby mě přeci jen chtěl někdo informovat, nebudu se bránit. Odkazy beru taky. Hlavně česky a srozumitelně (pro mě laika). Takže znovu díky všem, hlavně rastosovi. Už to tam láduju, tak uvidíme.
A pokud ho chci určit jak ho určím optimálně?Pokusem. 1M bývá v pohodě.
mimochodem1 - jaká je nastavená výchozí komprese?
man gzip
-# --fast --best Regulate the speed of compression using the specified digit #, where -1 or --fast indicates the fastest compression method (less compression) and -9 or --best indicates the slowest compression method (best compression). The default compression level is -6 (that is, biased towards high compression at expense of speed).
mimochodem2 - Co se stane když se mi bude vytvářet image větší než 4GB na flešku s FAT32?Jakmile se pokusíš zapsat přes 4 GB, hodí to file too large a zápis se nepodaří.
Měl bych i spoustu dalších otázek ohledně zobrazení stavu v %Pro dd: killall -USR1 dd, pro ostatní způsoby: vřadíš do kolony utilitu pv. Taky se dá kouknout do /proc/PID/fdinfo/FD.
nebo vyčištění diskuVytvoř veliký soubor plný nul (cat /dev/zero > soubor) a pak ho smaž. Na filesystémech, které jsou podporovány (obávám se, že jenom ext2/3/4), je lepší použít utilitu zerofree.
Tiskni Sdílej: