Inlägg

Om jag skulle gissa så får du meddelandet för att boken redan är utlånad och gissningsvis måste vänta ut tiden tills den är 'tillbakalämnad'

Vet inte hur biblioteks avtal är utformad men kan vara att de bara kan lämna ut ett visst antal böcker/licenser för en bok på samma gång och under en bestämd låneperiod på samma sätt som fysiska böcker.

Och du använder de korta medföljande USB-kablarna för dessa USB3 2.5" diskarna hoppas jag - inga långa USB3-kablar?

vill du använda långa USB3-kablar så är det mot externa 3.5" diskar med egen 12V strömförsörjningsadapter.

Strömkapaciteten för USB räknas per hub om 4 USB-uttag- inte per USB-uttag. Det innebär att har man flera olika 2.5" USB2/3-diskar så måste de ofta kopplas till olika USB-hubbar på moderkortet för att klara strömförsörjning av diskarna. Ofta finns det minst 2 USB-hubbar på en moderkort, ibland 3 men då är det ofta en USB2-hub för för tangentbord, mus och annat med låg kapacitetskrav i överföring, en USB3 en för 4 uttag bak på moderkortet ibland också ytterligare av USB2-typ för uttag 5 och 6 alternativt 4 USB2-uttag och 2 USB3-uttag.

Och den sista hubben för det som skall anslutas till frontpanelen - dessvärre ofta genom helt löjligt tunna kablar vilket gör att i praktiken inte går att koppla in någon extern USB2/3 snurrdisk på mer än 1, max 2 skivor att fungera något sånär pålitligt. och det är de tunna kablarna mellan moderkortets stiftuttag och chassiets fel...

inte zip - möjligen 7zip av anledning att 7zip också krypterar katalogen (efter att du bockat in det i GUI:t, av någon anledning är det inte default...) av filerna vilket zip inte gör utan lämnas i klartext.

Och har en tillräckligt svår och lång password som inte får träff i enligt https://haveibeenpwned.com/API/v3#SearchingPwnedPasswordsByRa... med 5 första hexvärdena av en SHA1-krypterad sträng av din password (utan nyradstecken efter! - kolla med välkänd password som abc123, 123456 etc. först att det ger ett svar med väldigt många förekomster (antalet anges efter ':'-tecknet) för att se din strängkonvertering till SHA1-hash fungerar som det skall) och sedan kolla resten själv i svaret om resterande hex-värden-strängen också fins på någon rad i svaret från webbsidan i dess svar på flera hundra rader. hittar du resten av SHA1-strängen även där så är din password inte tillräckligt unikt eller har läckt i någon databasläcka på någon site/forum du har besökt och skaffat konto hos.

Alternativet att du verkligen använder en maskinslumpad password på minst 12 tecken med siffror och symboler eller maskinslumpad passfras med minst 6 ord med skiljetecken från en diceware-lista då dessa sekvenser har extremt låg risk att få träff i haveibeenpwned-testet.

---

Det fins uppgifter av bl.a virusforskar fått sina passwordkrypterade zip-filer med virussampel borttagna av onedrive för att MS upptäckte att de innehöll virus...

Oklart om de bara tittade i filkatalogen på zipfilen och såg namnen på virus och drog slutsatsen att det var virusfiler eller om de faktiskt avkrypterade filen och konstaterade var virusfiler och tog bort dessa pga. att använda password var inte tillräckligt starkt.

du kan vara ganska så säker på att scanning görs på all data som du skickar upp till en molntjänst - för att tjäna pengar på dig och din data!

Om du laddar upp data molntjänst - se till att det är värdelös grus (=hårt krypterat med bra password som görs i din maskin innan detta sänds upp med någon molntjänstklient) och att du inte skicka upp värdefull malm till lagringen som de kan bearbeta (som kvittoinscanningar i klartext) ...

just 12V uttagen verkar ha blivit en standard som är ganska säker - passar kontakten (tex. en kraftaggregat för extern 3.5" USB-snurrdisk) så brukar det vara rätt med + på stiftet/innehylsan och '-' på ytterhylsan och diametrarna rätt

givetvis bör man dubbelkolla för att inte råka på undantaget som bekräftar regeln.

Hårddiskar är fortfarande det bästa för arkivering och backup - möjligen en molntjänst som den 3' offsite-backuppen/arkiveringen.

SSD/NVMe används för datat som hanteras för tillfället i sitt arbete.

Eftersom snabbhet verka viktig i letande så är molntjänst närmast uteslutet då det är rätt långsamma processer att ladda upp och hämta tillbaka - dessutom är många designade så att det är billigare att ladda upp men dyrare att hämta tillbaka - vilket många molntjänstkompatibla backupprogram är mycket väl medvetna om och därför försöker läsa tillbaka så lite data det går under sina backupprocesser.

tjänster som Blackblaze B2, som är bland de billigaste molnlagringstjänsten på marknaden och har resilens (dvs om filerna blir borttagna eller överskrivna med tex ransomware så finns versionerna kvar innan dess upp till 1-3 månader och därmed chans att hämta tillbaka dess oskadade versioner), tar 6 dollar per månad per TB - på 12 månader är det 72 dollar eller 762 kr/år/TB med dagens växlingskurs . - på 10 TB handlar det om 7520 kronor/år och för dessa pengar kan du köpa i princip 2 st 18 - 20 TB snurrhårddiskar - per år...

tittar du på amazon S3, Google Cloud eller Microsoft Azure så är priserna över 20$ per TB och månad.

Sedan går det givetvis hitta paketpriser på lagring som ger skenbart längre TB-kostnad som office365 mm. men kanske får betala på annat sätt (som att din data analyseras, drar slutsatser och i förlängningen tjänar pengar på detta)

Om tröskande av bilder känns långsam även med direktkopplade/USB hårddiskar så kanske det är en bra indexeringsprogram du skall titta på med datamässigt relativt lågupplösta minibilder som du kan bläddra snabbt mellan i letande och när du valt önskade bilder - då först rekvirerar ut bilderna med full upplösning från hårddisklagringen (som kanske är offline) och lägger dem i din laptops SSD/NVMe.

En hårddisk som ligger 'offline' och bara kopplas in då och då kan hålla mycket väl över 10 år i förvaring (i alla fall de som inte är heliumfyllda), men samtidigt har man aldrig data lagrad på en enda disk utan minst två olika på olika fysiska exemplar - och detta gäller oavsett om man lagrar på HD, SSD/NVMe, DVD och CD-skivor. man bör ha lagringen sådan sätt att man tål att en lagring försvinner/slutar att fungera precis när som helst utan att du har förlorat datan

tänk på att en NAS oavsett RAID och antal diskar räknas som en enda lagringsplats. - det är inte bara diskhaveri som kan göra att du förlorar data, det är hackning av servern/NAS och man får in ransomware som krypterar upp alla filer - och inte minst, förlust av filer pga. användarmisstag... en snurrdisk som är urkopplad och ligger i ett skåp kan inte virus hacka, medans allt som finns online kan angripas eller att man själv förstör datan av misstag på de olika ställena inom ganska kort tid om man har automatiska backupprocesser.

men å andra sidan om man duschar i 15 minuter med halvhögt flödet och beredaren är ställd 60 grader C så är det inte orimligt att vattnet börja bli dåligt varmt i slutskedet - höjer man till 85 grader så kanske man får en halv gång till i vattenmängd och det kanske räcker i 20-25 minuter istället.

du få ta en hink med inre gradering och sätta ned duschmunstycket i denna när du duschar normalt och sedan ta tiden till det når 10 liter - då först vet du mer exakt hur mycket vatten du faktiskt förbrukar per minut i din duschning.

---

Detta är något man får lära sig den hårda vägen att gå från brf/hyrehus till eget boende i villa/stuga att detta att kunna stå en halvtimme och mer i duschen utan att varmvattnet tar slut är en förgången tid...

...och man ser på elräkningen vad det kostar att stå länge i duschen... - kostnader man inte såg innan med brf/hyreshus...

Nibe brukar ha en svag knappt kännbar upphöjning/klack eller skrovlighet på skalan på panelen bakom termostatratten där det motsvarar 60 grader C och man skall inte ställa den kallare än så pga. legionellarisken (som är störst när man duschar iom. kan inandas små dim-droppar med bakterierna i sig medans risken är mindre om vattnet är för handtvätt eller bad utan att använda duschen) - max uppvriden brukar det stanna på 85 - 90 grader C.

På beredarens vattenintag bruka det finnas en blandningsventil som blandar ut den heta vattnet (viktigt när den är ställd på 85 grader) och en säkerhetsventil - ökar du temperaturen på beredaren så bör också blandningsventilen justeras så att varmvattnet som går mot duschen och varmvattenkranarna att det ligger på ca 55 grader C efter en kort tids spolande för att det inte skall vara skållningsrisk om man bara tappar hetvatten utan kallvatteninblandning i tappstället/duschen, men det skall heller inte vara kallare än 50 grader C då risken för legionella-tillväxt ökar fort med även några grader kallare varmvatten i rören.

Samtidigt skall man kolla och spola genom säkerhetsventilen (en svart ratt man vrider med fjädrande känsla moturs på och tills man hör att det börja spola) då och då så att den fungera som tänkt, men också kolla avtappningsrörets ända att den inte börja småläcka och droppa pga. kalkpåslag i ventilen - missar man sådant under lång tid så kan sådan läckage ge väsentligt högre elräkning om det sipprar varmvatten hela tiden.

Just detta att varmvattnet inte är tillräckligt varm hela vägen i rören tillräckligt ofta mot rummen/lägenheter i typisk inkvartering och hotell och även på färjor är orsaken till legionella-larmen man ser då och då. Detta gäller också i fastigheter med långa sträckor mellan panncentral till tappställen - speciellt där det sällan används (sällan använda rum).

Elelementet som värmer vattnet är i regel samma med samma resistans oavsett om det är enfaskopplat (230 Volt - 1 kW) eller kopplad mellan två faser i en tre-fas system (400 Volt - 3 kW) - om en säkring är gången oavsett enfas eller den ena av trefas så slutar det med att det är ingen värme alls i beredaren.

Kalkningsrisken (pannsten) finns alltid om vattnet är hårt och den ökar med varmare vatten och när effekten ökar på samma elementyta mot vatten - dvs. 3 kW värmning med 2 av de tre faserna gör att kalkbildningen ökar mer på elementslingan än om man kör på en-fas med 1 kW värme. - och det kan bli väldigt mycket kalk i en beredare - jag mins från när jag var liten och på vägghängd 300 liters beredare i ladugården med element-haveri att vid byte av elementet så ramlade det ut mer än en hink med kalkbitar från elementet, ursprungligen och i slutet innan haveriet var elementet i stort sett begravd i en stor hög med kalkbitar som med tiden hade sprättats/sprängs iväg från elementet i ångexplosioner.

En teknisk miniräknare har funktionen Y^x - vilket menas Y*Y*Y*...*Y x antal gånger (och tillåter också att x kan vara flyttal)

alla skrivbara ASCII-tecken räknas till 95 st - 94 st om mellanslag undantas

Så för 12 tecken password kan skrivas som 94¹² - dvs 94*94*94*...*94 tolv gånger vilket ger en entropi på 425.9*10²¹ olika möjliga kombinationer. Dela detta med 1*10¹² (tester per sekund) * 3600 (antal sekunder på en timme) * 24 (timmar på dygn) * 365 (antal dagar på året) = 15091 år och för 50% chans att hitta rätt så måste man ha räknat igenom halva mängden kombinationer dvs. 7546 år om man gör 1000 miljarder tester i sekunden.

Skulle man prova med 13 tecken så är det 94 gånger mer kombinationer än vid 12 tecken, dvs. 94¹³ ger 447*10²³ olika kombinationer.

svårigheten att räkna igenom alla alternativ ökar markant - istället för 7546 år för att komma igenom 50% vid 1000 miljarder tester per sekund så tar det med 13 tecken nu 1.4 miljoner år att nå 50% för att man la till ett enda tecken i sin password.

Med diceware-passfras är det samma sak - där har man en ord-alfabete (ordlista) på 7776 poster att välja mellan

med 6 ord blir det då 7776⁶ = 221.1 * 10²¹ ger att det tar 7010 år att räkna igenom hela volymen med 1000 miljarder tester i sekunden och man når 50% vid 3505 år. - även om använda ordlista är publik och alla känner till den och vet att den användes för att skapa passfrasen - så hjälper det inte i försöken att kunna hacka det fortare om passfrasen är sant slumpmässigt framtagen.

skulle vi ha 7 ords passfras - slumpade ur diceware-alfabetet så blir det 7776⁷ = 1.719 * 10²⁷ kombinationer - om vi kör hela raddan ovan igen så är vi uppe i 54.5 miljoner år för att räkna igenom alla kombinationer och för 50% ligger man då 27.26 miljoner år.

med andra ord antalet tecken i password och antalet ord i passfrasen är kung när det gäller att göra det svårhackat - så länge man låter dessa slumpas fram maskinellt eller med fysiska processer som vitt brus i grunden (eller med fysiska tärningskast vilket var dicewares idé när det gäller att välja passfras).

- så fort hjärnan skall hitta på något 'slumpmässigt' så kanske angreppet bara tar dagar och veckor... då algoritmerna, reglerna och filtren i hashcat, john the ripper och en bunt till har med olika analyser av befintliga läckor hittat huvuddragen hur folk gör när de skapar password och provar med det först och lyckas väldigt ofta - för vi människor gör ungefär på samma sätt vid samma situationer och undviker väldigt många alternativ som man tror att man inte kan lära sig utantill (vilket är korrekt) vilket gör att en 85 bitar starkt password om det är maskinslumpat hamnar under 50 bitar i styrka och kan knäckas på dagar och veckor när den tänks ut av hjärnor för att vi för ofta tänker på samma sätt när vi forceras att skapa 'slumpmässiga' password och passfraser.

tillägg:

enligt https://haveibeenpwned.com så är det nu ca 12.96 miljarder läckta unika password

det motsvarar att man utnyttjat 0.00000000000002723 (2.723 * 10⁻¹⁴) -del av antalet möjliga kombinationer som har läckt gentemot antalet möjliga kombinationer som går att skapa med en 12-teckens password.

Det fins alltså ordentligt med armbågsutrymme för nya varianter av password på 12 tecken storlek som _inte_ fins med i listan innan man börja krocka med någon annan som skapar en likadan kombination.

Som tidigare nämnts är bra password något som maskingenereras - inte någon hittepå från huvudet - det ironiska är att en del passwordsregler faktiskt kan rejekta fullt valida slumpässigt genererade password då att få en sekvens som saknar symbol, siffror eller inte blandar stor och små tecken är faktiskt rätt stor - och reglerna som införs minskar passwords möjliga entropi just för att man styr hur det skall utformas.

Själv kör jag på https://www.passwordcard.org/en och utskrivna i kreditkortformat (dubbelsidigt med och utan symboler och flera stycken inklusive rena nummerserie för numeriska pinkoder att välja mellan) och inplastat som källa när jag behöver får fram en slumpsekvens för password som inte är tillverkad av en hjärna och ändå 'har den kvar' om något skulle strula senare. att kunna sådana saker utantill är orimligt utan man låter browsern eller en passwordshanterar hantera detta.

det är flera gånger jag har fått byta rad/kolumn just för att 'passwordseglerna' rejektar sekvens för att de inte uppfyller kraven fast det är fullt valida och lika möjliga slumpvisa teckenserier rent etropimässigt.

För tjänster man kan göra reset på så låter jag ofta browsern själv generera passordet och komma ihåg detta..

för mer viktiga password som till sin huvudsakliga mailbox och bör kunna lära sig utantill så använder jag av mig passfraser genererade av

https://diceware.rempe.us/#swedish

6 ord med skiljetecken mellan orden ger styrka för motsvarande 3000 års angreppstid med 1000 miljard försök per sekund. och är det keystretching i funktionen som tar emot passwordet även med bara några tusen iteringar så blir det snabbt orimligt att försöka göra attack på det även med väldigt stor budget - inte minst kostnaden för energiförbrukning för angreppet...

Dessa har jag också skrivit ut i excel och dubbelsidigt på samma sätt som passwordcard gjort en stor antal rader att välja mellan på båda sidor och man bestämmer själv vilken rad, kolumn, flera korta rader, diagonalt, några från varsin sida etc. vilken man faktiskt använder, vilket gör att en sådan upphittat kort så är det fortfarande svårt att kunna användas av någon annan då man också måste veta vad som används till vilken situation. Med andra ord nål i höstacksprincipen att vet man inte var nålen är placerad så är det mycket att leta.

Att sätta upp en kompileringsmiljö så att den fungerar med alla PATH:ar (vilket är troligen ditt problem om den inte hittar .c och .h-filer och senare olika .lib-filer) kan vara rätt styvt jobb bara det och kostar mycket mer av tiden än att senare kompilera själva koden...

På den tiden var det typ Borlands kompileringamiljöer som många använde medans 'Bloodshed Dev' är inget jag någonsin hört talas om och har säkert sina egenheter att fixa innan den kompileringsmiljön snurrar - du får läsa dess manualer helt enkelt för att se hur du sätter upp kompileringsmiljön...

Det är en av de stora fördelarna i Unix/linux-världen sedan historisk tid är att det nästan alltid fanns en CLI version av C-kompilator som fungerar med alla sina sökvägar korrekta (för det mesta i alla fall) medans i DOS och windows-världen har det aldrig funnits någon utvecklingsmiljö för C-kod som fungerar utan alltid i form av på den tiden ganska dyra köpevaror.

och skulle man försöka med GNU-C så var det oftast via cygwin det fick köras.

Det läggs säkert in en massa gucka i UEFI-partitionen som speglar den gamla installationen och därför återvänder till den föregående setupen även vid ominstallation.

Därför måste partitionerna bort helt och helst göra 'zerofill' en bit in, ja kanske hela disken för att ta bort alla spår av gammal data som windows kan upptäcka igen och försöka återanvända igen under installationen. Det är en gammal regel ända sedan DOS-tiden när DOS och winistallationer inte fungerar som det skall trots flertal ominstallationsförsök och oftast så fungerar det efter att en zerofill gjorts i början av disken - orsak okänd varför...

En annan destruktiv kommando för att ta bort gammal oönskad data för just ssd/nvme är att köra 'blkdiscard' i linuxmiljö - då skickar det 'TRIM'/discard-kommando för lagringens hela LBA-adressområde och är så nära en secure erase man kan komma utan att just göra det.

8 tecken är alldeles för lite, ger 52,4 bit entropi om man räknar med alla skrivbara ascii-tecken utom blanktecken (94⁸)

det kör man igenom fullständigt på 1 timme och 42 minute med en större GPU-rigg som kan testa 1000 miljarder tester i sekunden, några veckor på enklare riggar med kralliga GPU:er

redan vid 12 tecken maskinslumpat så tar det mer än 3000 år att komma igenom till hälften med 1000 miljarder tester i sekunden

minst 15 tecken, helst maskinslumpade om du kör på windowsdator av olika historiska orsaker där brytpunkten till (stor) osäkerhet är vid 14 tecken pga. historisk NTLM V.1 och SMB V.1 infrastruktur i windows.

Har du provat med annan OS startad från USB-sticka (tex ubuntu live) och se om problemet kvarstår, kvarstår problemet så är det förmodligen en HW-fel eller skada på den tryckkänsliga skärmen som till och ifrån trycker iväg tecken repetitivt eller med flerpunktstryck samtidigt blockerar dina tryck. Detta kan interferera även om du kopplar in annan extern tangentbord.

om du kan stänga av tryckkänsliga skärmen (eller stänga av dess drivrutin) - blir det annorlunda ??

Vad får du för IP om du genom 5G-routern fråga på https://www.myip.com/ eller motsvarande med en browser - är det olika gentemot vad router själv säger i IP-adress så kör du genom ett CGNAT:at nät i någon led och därmed inga möjlighet att öppna publika portar.

Disken har bara varit igång 6000 timmar drygt - det är inget tid att tala om då de flesta brukar lätt passera 45000 timmar och relativt många kan nå både 80 och 90000 timmar - det under förutsättning att disken inte stängs av och startas hela tiden utan går kontinuerligt och när de stängs av så är de avstängda för en längre period per gång och när de varva upp så är det igång en längre period. - just start och stopp ofta, sliter... - om man ser dina värden verkar du ha kört 3 timmar och 52 minuter per gång.

nu skall det tåla fler starter än så innan problem - men att man inte låter disken bara gå och gå är en tänkbar faktor till den korta livslängden.

Den andra är vibrationer i chassie från tex. fläktar och/eller flertal inte så välbalanserade snurrdiskar samtidigt - här skiljer det sig mellan server och enterprise-diskar och konsumentdiskar i avseende tålighet mot vibrationer. Som redan nämnt så är det lagret bär läs/skriv armen som till slut får pitting i lagerbanorna mot kulorna när det står och skakar på samma läsposition hela tiden - dock brukar det inte ske märkbart inom 6000 timmar...

Om man tittar vidare i SMART så verkar det vara skrivning som skiter sig sista tiden - det fins inget om läsfel registrerat som inte har kunna felrättas till korrekt data (C6), sedan har det hittat 24 sektorer som upplevs veka men fortfarande läsbara (C5) - dessa försvinner igen om man skriver över sagda sektorer med ny data och resultat är endera lyckad skrivning eller reallokerad sektor.

På SATA-diskar så rättas tveksamma läsbara sektorer enbart direkt vid skrivning då det verifieras samtidigt som det skrivs med ett läshuvud bakom skrivhuvudet ett antal hundra nanometrar i avstånd - aldrig senare efter skrivning när det väl är gjort, hur många omläsningar som görs senare på en vek svårläsbar men rättningsbar sektor - skall man ha sådana funktioner med automatisk rättning av veka men läsbara sektorer så får man titta på SAS-diskar.

Med tanke på att C5 och C4 har skjutit ordentligt iväg i antal och förmodligen mestadels bara dina sista timmar så låter det som läshuvudfel eller att man har problem med skivans yta - och ett problem som existerat är tex. avdunstad olja från spindelmotorn försegling och labyrint-tätning - även om dessa droppar är extremt små så är dess storlek många gånger högre än läshuvudets normala flyghöjd (mindre än 10 nanometer) över diskytan och ställer till stora problem liknade att man kör en Ferrari på en motorcrossbana i +200 km/h

om man kör i linux i terminal med 'smartctrl -x /dev/sdx' där sdx är någon av sda, sdb sdc etc. och alternativen av vilka lagringar man har och kallas, kan fås fram med 'lsblk', så får man ofta ut mer information än standard SMART då det också fins en extended version av SMART som ibland kan berätta lite mer info.

---

Rädda ut så många filer du kan och när du nått värdens ända så blir det att försöka med 'ddrescue' under linux att få ut en diskimage av disken - se till att det är 3 filargument - inte 2, den tredje filargumentet håller reda på var den sökte sist och inte läser om redan läst data (som i nästa försök kan vara oläsbar) - utan den så börja den från början vid var start.

ddrescue är tillräckligt smart att hoppa över en bit vid områden som visar läsfel och försöker ta datat som är läsbar en bit efter och först i slutet av processen ger sig tillbaka på områdena med läsproblem och saxar sig in tätare och tätare till att det kanske är bara enskilda sektorer kvar som inte går att läsa oavsett antal försök.

det fins de som kört ddrescue halvårsvis på snurrdisk, som vid första skanning bara gav 50% läsbart - men ett halvår senare har nått 99.999% och bara fåtal sektorer den inte kunna tagit, vilket i många fall är betydelselösa och kan vara oanvänd utrymme på filsystemet.

Kan du 7zip:a eller annan arkiverande kompressionsprogram ihop hela trädet och sedan lägga den på roten av USB-stickan, fungerar det då men inte filträdet som det är, så har du troligen problem med träd-djupen.

De flesta komprimerande arkiveringsprogram har också checksummor i sig så du märker om arkivet gått trasigt när du packar upp igen eller kör en integritetstest på arkivet.

lagring som ger fel på filer är bara att kasta eller att reklamera om det är värt besväret (dvs. om den är tillräckligt dyr).

Se upp också med fejk-lagring som är stora i lagringsmängd till orimligt lågt pris då dessa kan vika ned skrivningar till att de börjar skriva över från början och skriva över det som redan är skrivet i typiska i någon av när man skriver förbi 8,16 ,32 ,64, 128 GB gränser. - detta ger att slå länge du bara skriver en mindre mängd data så ser minnet att fungera men går korrupt så fort du skriver över 1/8, 1/4, 1/2 av storleken som stickan anger i utrymme...

om inköpet/märket är tveksam kolla med lämpliga program som testar för fejkade USB-stickor och SD-minnen som registrerar sig med större storlek än vad de egentligen är då dessa lägger ut olika mönster tills lagringen är full och sedan kontrollerar om samma datamönster dyker upp igen på annan LBA-adress där det inte borde...