Coppwr, tj. GUI nástroj pro nízkoúrovňové ovládání PipeWire, byl vydán v nové verzi 1.6.0. Zdrojové kódy jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
Byla vydána dubnová aktualizace aneb nová verze 1.89 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í. Vypíchnout lze, že v terminálu lze nově povolit vkládání kopírovaného textu stisknutím středního tlačítka myši. Ve verzi 1.89 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-1 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Byla vydána verze 1.78.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
Služba Dropbox Sign (původně HelloSign) pro elektronické podepisování smluv byla hacknuta.
Byla vydána nová major verze 8.0 textového editoru GNU nano (Wikipedie). Podrobný přehled novinek a oprav v oznámení v diskusním listu info-nano nebo v souboru ChangeLog na Savannah. Volbou --modernbindings (-/) lze povolit "moderní" klávesové zkratky: ^C kopírování, ^V vložení, ^Z vrácení zpět, … Tato volba je aktivována také pokud binárka s nano nebo link na ni začíná písmenem "e".
Před 60 lety, 1. května 1964, byl představen programovací jazyk BASIC (Beginners' All-purpose Symbolic Instruction Code).
Byla vydána nová verze 12.0 minimalistické linuxové distribuce (JeOS, Just enough Operating System) pro Kodi (dříve XBMC) a multimediálního centra LibreELEC (Libre Embedded Linux Entertainment Center). Jedná se o fork linuxové distribuce OpenELEC (Open Embedded Linux Entertainment Center). LibreELEC 12.0 přichází s Kodi 21.0 "Omega".
Microsoft vydal novou velkou aktualizaci 2404.23 v září 2019 pod licencí SIL Open Font License (OFL) zveřejněné rodiny písma Cascadia Code pro zobrazování textu v emulátorech terminálu a vývojových prostředích.
OpenTofu, tj. svobodný a otevřený fork Terraformu vzniknuvší jako reakce na přelicencování Terraformu z MPL na BSL (Business Source License) společností HashiCorp, bylo vydáno ve verzi 1.7.0. Přehled novinek v aktualizované dokumentaci. Vypíchnout lze State encryption.
Použijte příkaz man dd ... parametr "noerror" by měl být pro "Ignoruje chyby při čtení"
Zadal bych "dd if=/dev/hda of=/dev/sdad1 conv=noerror" ... ano, hda je celé zařízení, včetně formátu disku, tedy včetně partiční tabulky apod.
Máte představu, co vlastně děláte? Chcete z toho dostat data? Neni lepší kopírovat jen /dev/hda1 a /dev/hda2 ... nebo brát přímo soubory?
Pěkné, asi bych postupoval stejně ... držím palce. A taky věřim, že TP je dost bezpečný, naštěstí i bohužel.
Ohledně klíče, bezpečnosti, by to mělo snad být tak, že je to záležitost elektroniky, řediče a disku.
Když není fyzicky poznat ten zkopírovaný, jak jste to zkoušel, jen připojením? Zkoumal jste, jaká data tam jsou zkopírována? Kdysi bych na ten disk koukal disk editorem ...
Na podrobnosti se ještě kouknu ... tuším, že je klíč někde mimo disk, už jsem o onu informaci kdysi zakop. Teď mne napadá jen testdisk, krom zmiňovaného ddrescue.
Doporučuje se obvykle system rescue cd ... jak procházim obsah, nic příhodného nevidim
No jo, já to jen opsal , taky jsem udělal tu samou chybu ...
Je to z jedna možností, ddrescue je další ... syntaxe je "ddrescue [options] infile outfile [logfile]", viz man ddrescue.
Já to jen vysvětlim ... vše je v linuxu soubor ... tedy i celý disk lze "chytit", adresovat, číst jako jeden soubor. Ať už zdrojový, nebo cílový.
A "fdisk -l /dev/sda" vypíše co? Zapsat libovolně velký soubor na zařízení lze pomocí "dd if=/dev/urandom of=/dev/sda bs=1000000 count=10000" ... lze upravit dle libosti (nějaké meze asi budou).
Jj ... nějak nás matete ... vidíte /dev/sdaf?
My vám to tolerujeme a pak se nedohodneme ... /dev/sda
vypadá líp ... stejně jako
device boot start end id system boot /dev/sdaf1 1 38913 7 hpfs/ntfs(opsal jsem to dobře?)
Chcete něco zkoušet? Měl byste mít jistotu, co chcete ... pokud je disk nějak vadnej, lze zkopírovat data normálně (např. cp). Pokud nejdou zkopírovat a disk už třeba nepřipojíte (takhle blbne mechanicky, když se dává do mrazáku?), tak udělat image celého disku ... to se dělá jako "dd if=/dev/hda of=/dev/sda" ... bez čísel, celý disk chcete ... a pak ho zpracovat ... jestli z něj, z té kopie něco dostanete, objevíte strukutru file systému apod.
Snad nekecam, že jsem slyšel, že zchlazení pomáhá, když se třeba disk neroztočí. Elektronka by šla vyměnit, když by šla, rozuměla si se zbytkem počítače.
Ohledně písmen, /dev/sdaf, google našel, že se to objevuje u lvm, virtualizace apod.
Děkuji za rpělivost, taky se učim.
Pokud se vytvoří nějaký nový filesystem, tak se musí ještě načíst ... nemůže to být tímhle? Při fdisku nějaký "ioctl" aktualizaci udělá ...
Jako jedinou možnost jsem zatim našel "hexedit" odkaz, aspoň pro nakouknutí, co tam vlastně je nakopírováno. Tedy použít by šlo "hexedit /dev/sdaf" zřejmě.
A máte hexedit k dispozici, je v tom slacku? Vypisuje něco "ls -l /dev/sda*" nebo "ls -l /dev/hda*"? Tedy je chyba v to, že hexedit nenašel disk nebo že hexedit není?
Budiž, "man ls" by Vám mělo napovědět, případně wiki ... chtěl jsem vidět víc toho, co vlastně máte v systému, zda je nějaký disk vidět jako zařízení.
To odpovídá/by snad odpovídalo. Vidíte to původní, co jste měl na tom malém disku. Jelikož je to zřejmě špatně přečtené, tak to neodpovídá stavu, jaký tam byl, když byl disk ok. Že je tam volné místo na konci je o tom, že se jedná o adresované/adresovatelné místo, které na tom původním disku/originálu nebylo.
Já to vidim, že máte nějakou kopii, disk, kde nejsou jen samé nuly, jsou tam nějaká data, ale nesedí čas od času, místo od místa, adresářová struktura ... musíte jít na low level přístup ...
Mohl byste hledat nějaké klíčové vazby, které na tom disku byly ... podle formátu souborů, které hledáte apod.
Sám jsem kdysi měl knížku od Marka Minasiho o správě hrdwaru ... tehdy jsem byl víc v obraze. Na FAT16 to byla ještě sranda. Ve Vaší situaci bych si asi to jednu těžce vydobytou kopii chránil a pracoval s další kopií (přes dd zase) ... můžete o ni pokusy přijít. Asi Vám na datech záleží.
S ruční obnovou NTFS zkušenost nemam. Zkusil bych projít jeden rozcestník, případně zkoušel na vlastní pěst se orientovat v NTFS, když vytvoříte prázdný NTFS disk, jak ho vidíte low level, když tam dáte soubor, jak se to projeví a tak. NTFS je starý docela dost dlouho, v linuxu je taky, co kontaktovat někoho okolo ntfs3g, podpory NTFS v linuxu, aspoň projít diskusní fóra?
Přišel jsi s notasem domů a při cca 20 nad nulou zformátoval disk (ten měl v tu dobu dejme tomu 50 stupňů), což způsobilo, že se na úplně magneticky čisté plotně vytvořily formátovací značky. při provozu ve 30 nad nulou už mohl mít i 80 stupňů a projevila se teplotní roztažnost materiálů (plotna, rameno hlav, šasi disku, ložisek) a při opakovaných zápisech nejspíš došlo k nepřesnostem v reálném nastavení hlavičky vůči plotně.
Teplotní kompenzaci si disk řeší sám. Tohle by možná platilo v případě, že by k tomu disku přistupoval na nízké úrovni a ještě přímo k plotně bez sektorů (pokud to vůbec jde). Při běžné ATA komunikaci by takováto chyba nikdy vzniknout neměla a disk by měl zahlásit chybu.
Tiskni Sdílej: