GPU-klasse</th>	Kandidater/sekund (mode 22000)</th>	`rockyou.txt</code> (14,3M) udtømt på</th></tr></thead>`
RTX 3090 (2022-æraen)</td>	~1,2M/s</td>	~12 s</td></tr>
RTX 4090</td>	~2,5–3M/s</td>	~5 s</td></tr>
RTX 5090-klasse (2025+)</td>	~5–8M/s</td>	~2–3 s</td></tr>
8× H100 cloud-instans</td>	~50M/s samlet</td>	<0,3 s</td></tr> </tbody></table> Mod en tilfældig 12+-tegns PSK</strong> (entropi ≈ 2⁷²) betyder ingen af disse tal noget — udtømmende søgning tager stadig årtusinder. Mod en 8-tegns ordbogsord-PSK</strong> betyder de alle sammen en hel del.</p> Hvorfor dette ikke rører WPA3</h2> Alt ovenfor målretter WPA2’s PSK-afledte 4-vejs håndtryk</strong>, som med vilje lader en offline observatør verificere PSK-gæt mod et capturet hash. WPA3-Personal erstatter dette med SAE</strong> (Simultaneous Authentication of Equals) — en protokol specifikt bygget så et passivt capture ikke giver noget crackbart offline. Der findes ikke et hashcat-mode til “cracke WPA3-SAE offline”, fordi protokollen ikke lækker det materiale, der skal til for at prøve.</p> Den praktiske vinkel mod WPA3 i 2026 er ikke at cracke SAE — det er at finde et access point, der stadig annoncerer WPA2/3-overgangstilstand</strong>, tvinge klienten til at forhandle WPA2-siden, og køre præcis angrebet ovenfor mod det fallback. Hvis netværket er rent WPA3 med PMF (Protected Management Frames) påkrævet, har denne playbook intet at byde på. Se 25 år med Wi-Fi-sikkerhed</a> for det fulde billede, inklusive Dragonblood-downgrade-forskningen dette afhænger af.</p> Defensiv pointe</h2> Hvis du læser dette for at tjekke dit eget netværk:</p> WPA3-Personal, ingen overgangstilstand.</strong> Tjek eksplicit — mange APs falder tilbage på WPA2/3-blandet tilstand, selv når WPA3 er “aktiveret”.</li> En lang, tilfældig PSK</strong> — 20+ tegn, ikke et ordbogsord eller telefonnummer. Det er det, der faktisk stopper hvert eneste angreb ovenfor koldt, WPA2 eller WPA3.</li> Deaktivér WPS.</strong> Urelateret til hashcat, men stadig ofte efterladt tændt og stadig en langt hurtigere vej ind for en angriber.</li> PMF påkrævet, ikke valgfrit</strong>, for helt at lukke af for deauth-drevet håndtryk-capture.</li> </ul> Se også rockyou.txt og ordlisternes tilstand i 2026</a> for hvad du faktisk skal loade ind i `-a 0</code>, og` `25 år med Wi-Fi-sikkerhed</a> for protokolhistorien bag alt dette.</p> </blockquote>` rockyou.txt: historien om verdens mest berømte ordliste (2026) 2026-07-03T00:00:00+00:00 Kort fortalt —</strong> rockyou.txt</code> er 14,3 millioner rigtige kodeord lækket i klartekst fra ét firmas databrud i 2009. Den blev standard-ordlisten for en hel generation af password cracking — bundlet i Kali Linux, citeret i hver eneste hashcat-tutorial, udødeliggjort som /usr/share/wordlists/rockyou.txt.gz</code>. I 2026 findes den stadig, men den er ikke længere det bedste værktøj til opgaven: weakpass.com’s aktuelle rangering placerer små kuraterede udsnit og løbende opdaterede ‘fundne kodeord fra virkeligheden’-lister over den. Dette indlæg dækker, hvor den kom fra, hvorfor den vandt, og hvad der reelt vinder nu.</p> December 2009: et firma der ikke hashede sine kodeord</h2> RockYou Inc.</strong> lavede Flash-baserede sociale-netværks-widgets — SuperWall, sjove foto-apps — til MySpace og Facebook, på højdepunktet af platform-app-boomet. I december 2009 eksponerede en SQL-injection</strong>-sårbarhed på RockYous side hele deres brugerdatabase: omkring 32 millioner konti</strong>.</p> Bruddet ville have været en fodnote, hvis ikke for én detalje: RockYou opbevarede kontoadgangskoder som klartekst</strong>. Ingen hashing, ingen salting — bare kodeordet, ordret, ved siden af e-mailadressen. Da dumpet cirkulerede, havde sikkerhedsforskere noget nærmest uhørt: millioner af rigtige kodeord, i klartekst</strong>, uden behov for cracking for at se, hvad folk faktisk valgte.</p> Efter fjernelse af dubletter endte den unikke kodeord-kolonne på ~14,3–14,4 millioner linjer</strong>, og den begyndte at cirkulere som en almindelig .txt</code>-fil under navnet på det brudte firma: rockyou.txt</code>.</p> Hvorfor den blev standarden</h2> Der skete masser af lækager før og efter 2009. rockyou.txt</code> blev specifikt standarden for pentest/CTF/red-team af nogle konkrete grunde:</p> Det var rigtige, uhashede, menneskevalgte data.</strong> Ikke en ordbog af engelske ord, ikke et genereret permutationssæt — rigtige kodeord rigtige mennesker skrev, med bias mod præcis den slags forudsigelige mønstre (iloveyou</code>, password1</code>, fødselsdatoer, tastatur-walks), som rigtige konti kompromitteres med.</li> Størrelsen passede til hardwaren fra tiden.</strong> 14,3M kandidater kørte til ende på en enkelt CPU eller tidlig GPU på rimelig tid — nyttig, ikke bare symbolsk.</li> Den var gratis og overalt.</strong> Ingen konto-mur, ingen nedtagning der holdt. Den blev bundlet i SecLists</strong> og leveret som standard i BackTrack</strong>, derefter Kali Linux</strong>, på /usr/share/wordlists/rockyou.txt.gz</code> — hvilket satte den på hver eneste pentesters maskine, uanset om de ledte efter den eller ej.</li> Engelsk-flertals-bias matchede flertallet af tidlige 2010’er-mål.</strong> Efterhånden som cracking-værktøjer blev globale, blev dette en begrænsning, ikke bare en fordel — men på det tidspunkt var det en hitrate-fordel.</li> </ul> I begyndelsen af 2010’erne var “kør rockyou.txt mod det” standardtrækket i næsten hvert eneste WPA-håndtryk, hashet database-dump eller CTF-udfordring med et kodeord-hash.</p> Navnet overlevede bruddet</h2> Her er den del, der overrasker folk: rockyou2021.txt</strong> og rockyou2024.txt</strong>, de kæmpestore efterfølger-navngivne lister du finder i dag, er ikke</strong> nye brud på RockYou Inc.</p> rockyou2021.txt</strong> dukkede op på et hacker-forum i juni 2021: omkring 8,46 milliarder linjer</strong>, sammensat ved at flette dusinvis af tidligere lækager, ordlister og algoritmisk genererede permutationer (case-varianter, leetspeak-substitutioner, tal-suffikser) — ikke friskstjålne credentials.</li> rockyou2024.txt</strong> fulgte samme mønster i 2024: omkring 9,95 milliarder linjer</strong>, endnu en community-megasammensætning.</li> </ul> Navnet “rockyou” blev genbrugt som et brand for “den største sammensatte cracking-ordbog lige nu”</strong>, løsrevet fra sin oprindelige betydning. Begge er rigtige, begge er enorme, og begge er værd at have — men ingen af dem fortæller dig noget om RockYou Inc.’s faktiske 2009-brugere. Behandl navnet som en genre-etiket, ikke en oprindelsespåstand.</p> Hvad weakpass.com’s rangering faktisk viser i 2026</h2> weakpass.com</a> er det tætteste, cracking-communityet har på et live ordliste-leaderboard: hundredvis af lister, hver med størrelse, antal linjer og en bogstavkarakter for effektivitet (S til F)</strong> — baseret på reel cracking-hitrate, ikke rå størrelse. At trække den aktuelle top af tavlen er mere interessant end noget enkelt tal:</p> Ordliste</th> Rang</th> Størrelse</th> Linjer</th></tr></thead> weakpass_4.merged.txt</code></td> S</td> 37,72 GB</td> 3,58 mia.</td></tr> all-h.txt</code></td> S</td> 28,51 GB</td> 2,72 mia.</td></tr> all-h.latin.txt</code></td> S</td> 28,35 GB</td> 2,71 mia.</td></tr> triple-h.txt</code></td> S</td> 21,82 GB</td> 2,13 mia.</td></tr> SAWL.txt</code></td> S</td> 17,02 GB</td> 1,49 mia.</td></tr> cyclone.hashesorg.hashkiller.combined.txt</code></td> S</td> 15,02 GB</td> 1,47 mia.</td></tr> hashpwn.txt</code></td> S</td> 14,11 GB</td> 1,35 mia.</td></tr> Hashes.org</code></td> S</td> 13,99 GB</td> 1,40 mia.</td></tr> dictionary_private.dic</code></td> S</td> 2,66 GB</td> 206,28 mio.</td></tr> hashmob.net_2025.user.found</code></td> S</td> 979,96 MB</td> 84,29 mio.</td></tr> rockyou-65.txt</code></td> S</td> 238,80 KB</td> 30,29 K</td></tr> weakpass_4a.txt</code></td> A</td> 81,37 GB</td> 8,44 mia.</td></tr> clatsdictionary.txt</code></td> A</td> 71,55 GB</td> 7,87 mia.</td></tr> rockyou2024.txt</code></td> B</td> 145,27 GB</td> 9,95 mia.</td></tr> rockyou2021.txt</code></td> B</td> 91,62 GB</td> 8,46 mia.</td></tr> rockyou.txt</code> (originalen)</strong></td> C</strong></td> 133,44 MB</strong></td> 14,34 mio.</strong></td></tr> </tbody></table> Den sidste række er den interessante. Den originale rockyou.txt</code> — filen der definerede et årti af tutorials — rangerer under</strong> både et 238-kilobyte kuraterede udsnit af sig selv og de milliard-linjers megasammensætninger, der lånte dens navn. Tre ting sker på samme tid:</p> 1. Rang måler hitrate, ikke størrelse</h3> weakpass bedømmer efter cracking-effektivitet</strong>, ikke rå antal linjer. En lille, omhyggeligt kurateret liste, der rammer en høj procentdel af rigtige kodeord pr. forsøgt kandidat, rangerer over en vidtstrakt liste polstret med permutationsstøj. Derfor sidder rockyou-65.txt</code> — et udsnit på 30.290 linjer, 238 KB</strong> — i S-klasse</strong>, samme kategori som 30+ GB megalister, mens originalen med 14,34 millioner linjer sidder tre klasser lavere.</p> 2. Procentvis udsnit af rockyou er en reel teknik</h3> weakpass udgiver en hel familie af rockyou-XX.txt</code>-filer — rockyou-5.txt</code> op til rockyou-75.txt</code> — hver et sandsynlighedsvægtet udsnit af originalen, holdt i faldende rækkefølge efter observeret hyppighed. rockyou-5.txt</code> er 13 linjer; rockyou-75.txt</code> er 59.190. Ideen: til en hurtig første gennemgang mod et stort sæt hashes udgør de øverste 5–15% af rockyou.txt</code> efter observeret hyppighed ofte en uforholdsmæssig stor andel af de crackbare konti. Prøv det lille udsnit først; grib kun til den fulde 14,3M-linjers liste, eller efterfølgerne på milliarder af linjer, hvis det hurtige gennemløb kommer tomhændet tilbage.</p> Udsnit</th> Størrelse</th> Linjer</th></tr></thead> rockyou-5.txt</code></td> 104 Bytes</td> 13</td></tr> rockyou-25.txt</code></td> 7,06 KB</td> 929</td></tr> rockyou-50.txt</code></td> 74,13 KB</td> 9,44 K</td></tr> rockyou-65.txt</code></td> 238,80 KB</td> 30,29 K</td></tr> rockyou-75.txt</code></td> 467,72 KB</td> 59,19 K</td></tr> rockyou.txt</code> (fuld)</td> 133,44 MB</td> 14,34 mio.</td></tr> </tbody></table> 3. “Fundet i naturen, i år” slår “lækket engang, for et årti siden”</h3> Det andet mønster i toppen af S-klassen: hashmob.net_2025..found</code></strong>-listerne. hashmob.net</a> er et levende community-hub for hash-cracking — kodeord-hashes bliver indsendt, communityet cracker hvad det kan, og de succesfuldt crackede klartekster udgives tilbage som ordlister, løbende opdateret. Fordi de repræsenterer kodeord folk vælger lige nu</strong>, ikke kodeord folk valgte i 2009, har de en aktualitetsfordel, ingen statisk lækage kan matche, uanset størrelse.</p> Hvad det betyder i praksis</h2> Hvis du vælger en ordliste i 2026, er “største fil” den forkerte tommelfingerregel:</p> Start småt og målrettet.</strong> Et kurateret udsnit (rockyou-65.txt</code>) eller en frisk “fundet”-liste slår en 100 GB megafil til en første gennemgang — det er færdigt på sekunder og rydder ofte en meningsfuld del af de svage konti.</li> Tilføj regler før størrelse.</strong> hashcat -a 0 -r best64.rule</code> (eller den langt større OneRuleToRuleThemAll.rule</code>) mod en beskeden basisliste genererer størrelsesordener flere effektive kandidater end den samme liste kørt rå — og slår normalt en større umuteret liste for samme tidsbudget.</li> Grib til megalisterne til sidst.</strong> rockyou2021.txt</code>, rockyou2024.txt</code>, weakpass_4.merged.txt</code> og lignende er værd at have til udtømmende offline-arbejde mod et hash-sæt, du har råd til timer eller dage imod — ikke som det første, du prøver.</li> Den originale rockyou.txt</code> er stadig en fin baseline</strong> — gratis, lille nok til hurtig iteration, velforstået — bare ikke længere loftet.</li> </ol> Se hashcat WiFi-cracking i 2026</a> for disse ordlister i aktion mod et rigtigt WPA-håndtryk, og 25 år med Wi-Fi-sikkerhed</a> for den bredere angrebs- og forsvarshistorie.</p> </blockquote> Fine-tuning af Whisper til danske telefonopkald: en LoRA-obduktion (2026) 2026-07-02T00:00:00+00:00 Kort fortalt —</strong> Fine-tunede whisper-large-v3</a> på CoRal-project/coral-v3</a> (rigtig, menneske-transskriberet dansk tale) med en LoRA-adapter, telefon-kodek-augmenteret for at lukke hullet til rigtig telefonlyd. Træningstabet sad fast på samme plateau tre gange i træk</strong>, og hver gang så forklaringen anderledes ud — indtil det viste sig at være én kedelig skemalægningsfejl. Rettet, og modellen halverede næsten word error rate</strong> på tilbageholdt dansk tale. Så fandt en systematisk gennemgang af rigtige telefonoptagelser, at benchmark-tallet ikke fortalte hele historien. Udgivet alligevel — på Hugging Face</a>, med et ærligt modelkort.</p> Fine-tuning-efterfølgeren til transskribering af 33.000 danske voicelogs på hjemme-GPU’er</a>. Det indlæg valgte basismodellerne; dette forsøger at gøre en af dem bedre.</p> </blockquote> Tabet, der ikke ville bevæge sig</h2> Opsætningen: PEFT</a> LoRA (rank 32, alpha 64, q_proj</code>/v_proj</code>) oven på whisper-large-v3, trænet på ~9.000 lydstykker fra coral-v3 — tre fjerdedele kørt gennem en telefon-kodek-simulering (8kHz-båndbreddegrænse, lav-bitrate-mp3-rundtur, let støj), så modellen ville se noget tættere på rigtig opkaldslyd end coral-v3’s rene studieoptagelser.</p> Krydsentropi-tab bør starte højt og falde til enkeltcifrede tal, efterhånden som træningen konvergerer. I stedet gjorde tre separate forsøg det samme: et skarpt indledende fald, derefter et hårdt plateau omkring 35-40, der aldrig bevægede sig, uanset hvor længe træningen kørte. Hvert forsøg pegede på en anden synder — og hver rettelse var reel, og ingen af dem løste det faktiske problem:</p> Mistænkt: dårlig lyd.</strong> Coral-v3’s rå optagelser viste sig at have vildt uensartede lydstyrker — nogle stykker praktisk talt næsten stille (median-RMS en størrelsesorden under sund tale). Whispers feature-extractor er følsom over for absolut amplitude, så dette var en reel fejl. Rettet med lydstyrkenormalisering (EBU R128, -16 LUFS) på hvert stykke. Tabet: sad stadig fast på 35-40.</strong></li> Mistænkt: dobbeltbehandling.</strong> Træningsscriptet genanvendte et støj-/EQ-filter beregnet til rå, ubehandlet</em> produktionslyd på data, der allerede var fuldt forbehandlet — en rest fra genbrug af kode skrevet til en anden datakilde. Bekræftet ved direkte måling: det overflødige filter pressede nogle stykkers lydstyrke lige tilbage ned. Rettet. Tabet: sad stadig fast på 35-40.</strong></li> Mistænkt: modellen selv.</strong> Med begge lydfejl rettet og plateauet uændret, skiftede arbejdsteorien til, at læringsraten var ustabil for den fulde</em> whisper-large-v3 (32 decoder-lag) versus den mindre turbo-variant (4 lag), som en tidligere, vellykket fine-tuning havde brugt. En kontrolleret test — samme LoRA-konfiguration, samme kendt-gode data, kun basismodellen udskiftet — genskabte det identiske plateau. Test af en 5x lavere læringsrate gav et identisk</em> resultat. Det var beviset: to forskellige læringsrater, der konvergerer til præcis den samme “fastsiddende” værdi, er ikke et læringsrate-problem.</strong></li> Den faktiske fejl.</strong> Warmup-skemaet var 100 skridt, og hvert testkørsel — inklusive, viste det sig, de rigtige</em> træningskørsler — blev kun nogensinde observeret midtvejs gennem den optrapning. Læringsrate-skemalæggeren klatrede stadig mod sin målværdi hele tiden, nogen havde kigget på den. Et kort, proportionalt warmup (40 af 548 samlede skridt) konvergerede rent i det allerførste efterfølgende forsøg: 98 → 83 → 68 → 54 → 39 → 26 → 16 → 13 → 11 → 9,5</strong>, der fulgte næsten præcis banen for en tidligere, allerede bevist fine-tuning.</li> </ol> To af de tre rettelser var reelle fejl, det var værd at rette i sig selv. Ingen af dem var den</em> fejl. Lektionen generaliserer ud over dette ene projekt: en metrik, der ser “fastsiddende” ud, kan bare være et skema, der ikke er færdigt med at trappe op</strong> — tjek det, før du konkluderer, at noget grundlæggende er i stykker.</p> (En mindre, separat fejl undervejs: parallelisering af data-forberedelsestrinnet med en trådpulje gav nondeterministiske nedbrud med en PyGILState_Release</code>-fejl — et C-udvidelses-trådproblem, ikke min kodes logik. En procespulje, som giver hver worker sin egen uafhængige interpreter-tilstand, løste det fuldstændigt. Foretræk procespuljer frem for trådpuljer, når arbejdet er C-udvidelsestungt</strong> (lydafkodning, kodek-kald) frem for ren Python.)</p> Benchmarket: en reel gevinst</h2> Med træning, der rent faktisk konvergerede, den rigtige test: et tilbageholdt sæt coral-v3-stykker (adskilt fra træningen — garanteret ved at springe det nøjagtige antal stykker over, som træningen brugte, fra den samme deterministiske blanding) med rigtig ground truth, så word error rate kan beregnes direkte i stedet for at blive vurderet med øjemål.</p> model</th> samtale-dansk WER</th> oplæsnings-dansk WER</th></tr></thead> whisper-large-v3 (utrænet)</td> 0,704</td> 0,303</td></tr> fine-tunet (dette indlæg)</strong></td> 0,367</strong></td> 0,220</td></tr> CoRals egen formålsbyggede danske model</td> 0,327</td> 0,101</td></tr> </tbody></table> Næsten en halvering</strong> af samtale-WER fra en generisk basismodel, der lukker det meste af hullet til en model bygget fra bunden til dansk. Oplæsningstallet forbedredes mindre, fordi træningen kun brugte coral-v3’s conversation</code>-split — en klar, testbar forudsigelse, der holdt stik (formel, skriptet tale er en anden fordeling end uformel samtale, og modellen så kun den ene af dem).</p> Men WER var ikke hele historien</h2> Et WER-tal er en samlet størrelse: det fortæller dig hvor meget</em> tekst der afviger fra referencen, ikke hvilken slags</em> fejl der er tale om. En model, der af og til erstatter et rigtigt ord med et andet, forkert-men-plausibelt ord, og en model, der af og til finder på en selvsikker, flydende, helt fabrikeret sætning, kan opnå den samme</em> WER — men kun den ene af dem er sikker at bruge uden opsyn.</p> Så: en systematisk kvalitativ gennemgang, på rigtige (ikke benchmark-) telefonoptagelser — det faktiske måldomæne, ikke en stedfortræder for det. Hvert output fra den fine-tunede model blev sammenlignet med fem andre modellers transskriptioner af den samme lyd, specifikt på udkig efter indhold uden opbakning noget andet sted: et opdigtet navn, en opdigtet detalje, en påstand der ikke blev sagt. (Intet opkaldsindhold gengives her — optagelserne er private forretningsopkald; kun det samlede resultat betyder noget for dette indlæg.)</p> Resultatet: omtrent hvert ottende opkald viste en klar fabrikation</strong> — indhold sagt med selvsikkerhed, som ingen anden model, og formodentlig ingen på opkaldet, rent faktisk sagde. Omkring halvdelen af opkaldene var i praksis ækvivalente med den utrænede baseline, og det meste af resten adskilte sig kun i formulering eller udeladelse, ikke opdigtning. Et genuint interessant sidespring: den utrænede basismodel</em> har sin egen velkendte fejltilstand på stille lyd (en specifik hallucineret “falsk undertekst-credit”-linje, en dokumenteret Whisper-artefakt), der dukkede op på en sammenlignelig andel af opkald — og den fine-tunede model genskabte aldrig den specifikke fejl, hvilket tyder på, at fine-tuningen byttede én fejlklasse ud med en anden i stedet for blot at lægge et nyt problem oven på en ren baseline.</p> Samlet vurdering:</strong> en reel, betydelig nøjagtighedsforbedring på den metrik, der er let at måle, og et reelt, ikke-trivielt pålidelighedshul på den egenskab, der rent faktisk betyder noget for brug uden opsyn — opdigtede navne og enheder er præcis det forkerte at få galt i et system, der bruges til at spore, hvem der sagde hvad. Ingen af de to kendsgerninger ophæver den anden.</p> Udgivet alligevel</h2> Adapteren er på Hugging Face: x2q/whisper-large-v3-da-coral-lora</a></strong>. Modelkortet angiver WER-tallene, træningsdata og licens (coral-v3 er OpenRAIL-licenseret og citeret direkte — ingen grund til at skjule et legitimt, statsstøttet dansk tale-datasæt bag en vagere beskrivelse), fabrikationsrate-fundet, og en konkret brugsadvarsel: brug den ikke som eneste kilde til automatisk navne-/enhedsudtræk uden en anden model eller et menneske i løkken.</p> En mangelfuld model med et ærligt kort er mere værd for den, der finder den, end en tavs én.</p> Lektionerne, destilleret</h2> En fastsiddende metrik kan bare være et ufærdigt skema</strong> — tre plausibelt lydende grundårsager (dårlig data, dobbeltbehandling, læringsrate-ustabilitet) var alle reelle fejl og alle forkerte om den faktiske årsag, som var en warmup-optrapning, ingen havde ladet færdiggøre, før de drog konklusioner.</li> To forskellige værdier, der konvergerer til det identiske forkerte svar, er et stærkt signal</strong> — hvis ændring af en hyperparameter ikke ændrer resultatet, er hyperparameteren sandsynligvis ikke årsagen.</li> Procespuljer frem for trådpuljer til C-udvidelsestungt parallelt arbejde</strong> — et nondeterministisk nedbrud på interpreter-niveau forsvandt fuldstændigt, da hver worker fik sin egen proces i stedet for at dele én interpreters GIL-tilstand.</li> En enkelt samlet metrik kan ikke se fejltilstands-diversitet</strong> — WER behandler et forvansket ord og en selvsikkert opdigtet sætning ens. Hvis de to betyder noget forskelligt for dit brug (det gør de næsten altid), har du brug for en kvalitativ gennemlæsning, ikke bare et bedre tal.</li> Udgiv fejlen, ikke kun gevinsten</strong> — en dokumenteret fejlrate med klar brugsvejledning er et mere nyttigt artefakt end et pænt udseende modelkort, der viser sig at skjule det samme problem, basismodellen allerede havde.</li> </ol> Fem alternativer til pyannote: speaker diarization til telefonopkald (2026) 2026-06-24T00:00:00+00:00 Speaker diarization — at afgøre “hvem talte hvornår” — lyder simpelt og viser sig at være svært. Dette indlæg dokumenterer et weekendeksperiment med fem alternative tilgange til min nuværende produktionspipeline.</p> Baggrund</h2> Jeg optager og transskriberer alle mine erhvervsopkald automatisk. Pipelinen er groft sagt:</p> Opkald ankommer, audio gemmes som MP3</li> Whisper</a> transskriberer til ordniveausegmenter</li> Et diarization-trin tildeler hvert segment en taler</li> Alt lander i en SQLite-database med et Markdown-resumé</li> </ol> Trin 3 er det interessante. Jeg landede på pyannote/speaker-diarization-3.1</strong> som produktionsbackend efter at tidligere eksperimenter udelukkede NeMo MSDD, reference-guided ECAPA og DiarizationLM. Pyannote virker pålideligt — men den bruger 4–5 sekunder pr. opkald og kræver en Hugging Face-token med accepterede modelvilkår. Jeg ville vide, om nyere forskning har produceret noget meningsfuldt bedre.</p> Benchmark</h2> 8 rigtige opkald, 288–592 sekunder, alle 2-partssamtaler.</strong> Jeg kører hvert alternativ mod pyannotes output og måler segment-level agreement</em>: andelen af Whisper-segmenter, hvor alternativet tildeler samme speaker-label som pyannote, under den bedste permutationsmapping.</p> Dette måler lighed med pyannote</em>, ikke absolut korrekthed. En metode der afviger fra pyannote kan faktisk have mere</em> ret — der er ingen human ground truth at sammenligne med. Husk det, når du læser tallene.</p> Alle fem bruger pyannotes interne WeSpeaker ResNet34-LM</strong> embedding-model (256-dim, cosine, trænet på VoxCeleb) — samme model pyannote bruger internt, så den er allerede indlæst.</p> Baseline — EXP E (udgik tidligt)</h2> Inden F–J prøvede jeg at bygge taler-referencer fra pyannotes egne labels i databasen og køre WeSpeaker nearest-neighbour mod dem. Den nåede 88 % agreement — men er cirkulær: den bruger pyannotes labels som input. Ubrugelig som erstatning.</p> EXP F — WeSpeaker + Spectral Clustering</h2> Idé:</strong> SpectralClustering med normaliseret cosine-affinitet slår AgglomerativeClustering på 2-taler-opgaver (Park et al. ICASSP 2022; Landini et al. IS 2022). Den globale grafstruktur slår grådige lokale sammensætninger.</p> Flow:</strong></p> Gruppér Whisper-segmenter i turns (< 0,5 s pause = samme turn)</li> Embed hvert turn med WeSpeaker ResNet34 (256-dim, L2-normaliseret)</li> Byg cosine-affinitetsmatrix, kør SpectralClustering(n_clusters=2)</code></li> Map klyngerne til navne via opkaldsretning</li> </ol> Tid:</strong> ~0,2 s — 25× hurtigere end pyannote.</p> EXP G — Multi-scale WeSpeaker + AHC</h2> Idé:</strong> Korte turns giver ustabile embeddings. Løs det ved at embedde hvert turn i tre vinduesstørrelser — 0,5×, 1× og 2× turn-varighed centreret om turn-midten — og middel de tre embeddings. Inspireret af NeMos MSDD-arkitektur (Kwon et al. 2022).</p> Flow:</strong> Samme som F, men brug det middelte multi-scale embedding. Clustering med AgglomerativeClustering (cosine</code>, average</code> linkage).</p> Tid:</strong> ~0,6 s.</p> EXP H — WeSpeaker + PLDA + Spectral Clustering</h2> Idé:</strong> PLDA (Probabilistic Linear Discriminant Analysis) modellerer within- og between-speaker-kovarians og slår konsistent cosine-distance til speaker clustering (Snyder et al. 2018; dominerende i VoxSRC 2023-vindersystemer).</p> pyannote-audio</code>-pakken medfølger et trænet PLDA-objekt med LDA-transformationen _xvec_tf</code> og egenværdierne phi</code>.</p> Flow:</strong></p> LDA-projektion: mat_lda = plda._xvec_tf(embeddings)</code> — reducerer 256 → 128 dim</li> Pairwise Simplified-PLDA log-likelihood ratio: φ</code> = PLDA-egenværdier (plda.phi</code>, 128-dim)</li> w_same = φ / (φ + 2)</code> — vægt for at x og y er samme taler</li> w_diff = 1 / (φ + 1)</code> — straf for at de er forskellige</li> LLR(x, y) = Σ [ w_same·(xᵢ+yᵢ)²/2 − w_diff·(xᵢ²+yᵢ²)/2 ]</code></li> </ul> </li> Konvertér til affinitet: A = 1 / (1 + exp(−LLR))</code></li> SpectralClustering(n_clusters=2, affinity="precomputed")</code></li> </ol> Tid:</strong> ~0,3 s.</p> EXP I — Silero VAD + WeSpeaker + Spectral Clustering</h2> Idé:</strong> Whisper-segmentgrænser er semantiske, ikke akustiske — de følger meningen, ikke mundens åbning. Bedre VAD-grænser giver renere embeddings. VBx-systemet (Landini et al. Odyssey 2022) viser, at nær-oracle VAD er kritisk for embedding-kvalitet. Silero VAD (Silero Team 2021) kører på CPU og bruger ~1 ms pr. sekund audio.</p> Flow:</strong></p> Kør Silero VAD på rå audio (threshold=0.4</code>, min_speech=250 ms</code>, min_silence=300 ms</code>)</li> Gruppér Silero-timestamps i turns (< 0,5 s pause)</li> Embed hvert Silero-turn med WeSpeaker</li> Map Whisper-segmenter til nærmeste Silero-turn via tidsoverlap</li> SpectralClustering(n_clusters=2)</code></li> </ol> Tid:</strong> ~2,1 s (domineret af Silero på CPU).</p> EXP J — Cross-call speaker gallery (nearest-neighbour)</h2> Idé:</strong> Ingen clustering overhovedet. Byg i stedet et galleri af kendte talere fra historiske kald i databasen, og klassificér nye turns med cosine nearest-neighbour — som i speaker-recognition-litteraturen (Ding et al. ICASSP 2020; x-vector NN-baseline i VoxSRC 2021–2023).</p> Flow:</strong></p> Hent de seneste 40 færdigbehandlede kald fra DB</li> Sample op til 8 WeSpeaker-embeddings pr. taler pr. kald → {taler: [emb, ...]}</code></li> Beregn middelembedinget pr. taler, L2-normaliser</li> For hvert nyt turn: find galleri-taleren med højeste cosine-similaritet</li> Snap til linje-ejer eller modpart baseret på opkaldsretning</li> </ol> Tid:</strong> ~0,2 s ekskl. gallery-opbygning (12 s én gang ved opstart, derefter cached).</p> Resultater — 8 opkald</h2> Opkald</th> Varighed</th> Pyannote-fordeling</th> F SC</th> G MS</th> H PLDA</th> I Silero</th> J Gallery</th></tr></thead> Kald A</td> 308 s</td> 68 / 34 seg.</td> 66,7 %</td> 65,7 %</td> 88,2 %</strong></td> 88,2 %</strong></td> 69,6 %</td></tr> Kald B</td> 288 s</td> mono</strong> (10/0)</td> 80,0 %</td> 90,0 %</td> 80,0 %</td> 90,0 %</td> 80,0 %</td></tr> Kald C</td> 320 s</td> 4 / 33 seg.</td> 75,7 %</td> 86,5 %</strong></td> 78,4 %</td> 81,1 %</td> 75,7 %</td></tr> Kald D</td> 314 s</td> mono</strong> (99/0)</td> 35,4 %</td> 1,0 %</td> 35,4 %</td> 61,6 %</td> 47,5 %</td></tr> Kald E</td> 384 s</td> 20 / 39 seg.</td> 62,7 %</td> 64,4 %</td> 66,1 %</td> 74,6 %</strong></td> 69,5 %</td></tr> Kald F</td> 393 s</td> mono</strong> (84/0)</td> 40,5 %</td> 1,2 %</td> 10,7 %</td> 48,8 %</td> 47,6 %</td></tr> Kald G</td> 401 s</td> 63 / 90 seg.</td> 58,8 %</td> 59,5 %</td> 57,5 %</td> 88,9 %</strong></td> 62,1 %</td></tr> Kald H</td> 592 s</td> 43 / 64 seg.</td> 71,0 %</td> 58,9 %</td> 70,1 %</td> 75,7 %</strong></td> 64,5 %</td></tr> Gennemsnit</strong></td> </td> </td> 61,3 % ±15 %</td> 53,4 % ±32 %</td> 60,8 % ±24 %</td> 76,1 % ±14 %</strong></td> 64,6 % ±11 %</td></tr> </tbody></table> Pyannote-referencetid: 5,1 s</strong> gennemsnit pr. opkald.</p> Kald B, D og F er “mono” — én part dominerer næsten 100 % af segmenterne. Disse er de sværeste cases.</em></p> Tre overraskelser</h2> 1. EXP G kollapsede fuldstændigt på mono-kald</h3> 1,0 % og 1,2 % agreement. Det er ikke bare dårligt — det er aktivt forkert. AHC med n_clusters=2</code> tvinger to klynger uanset hvad: på mono-kald ender den med én kæmpe klynge og én med nærmest ingen segmenter, og den globale label-swap-permutation redder det ikke. Multi-scale hjalp intet.</p> Spectral Clustering (F, H, I) er lidt mere robust — 35–61 % på de samme kald — men kollapsede stadig. Ingen af de fem tilgange ved</em> at der kun er én taler.</p> 2. PLDA — 88 % på rigtige 2-taler-kald, 10 % på mono</h3> PLDA-metoden (H) klarede sig bedst på kald med to tydeligt adskilte talere. Det er præcis hvad PLDA er designet til: at modellere forskellen i embedding-rummet mellem to taler-distributioner. Men på mono-kald splitter den alligevel, og ender med en worst-case på 10,7 %.</p> 3. Gallery-metoden var den mest stabile (±11 %)</h3> EXP J vandt ikke i gennemsnit, men havde langt laveste varians. Den “ved” hvem linje-ejeren er fra historiske kald og gætter rimeligt på modparten. Fejler systematisk på talere den aldrig har hørt — første gang en ny kontakt ringer er gallery-embeddinget tomt for den person.</p> Konklusion</h2> Vandt: EXP I (Silero VAD + WeSpeaker + SC)</strong> — 76,1 % agreement, 2,4× hurtigere end pyannote (2,1 s mod 5,1 s).</p> Forklaringen er at Sileros akustiske VAD-grænser giver renere turn-segmenter end Whispers semantiske grænser. Whisper skærer, hvor meningen stopper; Silero skærer, hvor munden stopper. Renere segmenter → renere embeddings → bedre clustering.</p> Forblev på pyannote 3.1 i produktion.</strong> Alle fem alternativer fejler på mono-kald, og mono-kald er et reelt scenarie i en produktionspipeline. Nær-ensidigt kald, mistet forbindelse, kort bekræftende svar — ingen af dem håndteres korrekt af klyngemetoder med fast n_clusters=2</code>.</p> Den mest lovende sti fremad: EXP I + 1-taler-detektor.</strong> Beregn cosine-variansen inden for en turns embeddings; er variansen under en grænseværdi, er opkaldet sandsynligvis mono og alle segmenter tildeles linje-ejeren. Det ville sandsynligvis nå 85–90 % agreement ved ~2,5 s total — sammenlignelig med pyannote på rigtige 2-taler-kald og korrekt på mono-kald.</p> Se den fulde pipeline</a> og Whisper backend-benchmarks</a> for den bredere kontekst dette eksperiment lever i.</p> </blockquote> Apple M1 Pro vs RTX 4070 Ti til lokal AI — GPU-matmul og LLM-benchmarks (2026) 2026-06-22T00:00:00+00:00 Kort fortalt —</strong> En 4096×4096 float16 matrixmultiplikation afslører et 18× rå beregningsgab</strong>: RTX 4070 Ti rammer 75 TFLOPS via tensor cores; M1 Pro MPS når 4,2 TFLOPS. Men kør en rigtig LLM, og gabet kollapser til 3–4×</strong> — fordi tokengenerering ved batch størrelse 1 er hukommelsesbåndbredde-begrænset, ikke beregnings-begrænset. Begge maskiner kan køre nyttige modeller lokalt; de bytter på VRAM-loft vs hastighed.</p> Ledsager til Rust vs Go vs C på de samme maskiner</a> — samme hardware, anderledes spørgsmål.</p> </blockquote> Opsætning</h2> </th> M1 Pro (Metal/MPS)</th> RTX 4070 Ti (CUDA)</th></tr></thead> Maskine</strong></td> Apple MacBook Pro</td> Desktop-PC</td></tr> GPU</strong></td> M1 Pro 16-kerne GPU</td> NVIDIA GeForce RTX 4070 Ti</td></tr> VRAM / GPU-mem</strong></td> 16 GB unified (delt med CPU)</td> 12 GB GDDR6X</td></tr> CPU</strong></td> M1 Pro, 8-kerne (6P+2E)</td> Intel i5-13400F, 16 tråde</td></tr> RAM</strong></td> 16 GB</td> 125 GB</td></tr> OS</strong></td> macOS 26.6</td> Ubuntu 24.04, CUDA 12.1, driver 595</td></tr> PyTorch</strong></td> 2.7.0, MPS-backend</td> 2.5.1+cu121</td></tr> ollama</strong></td> 0.30.8</td> 0.30.8</td></tr> </tbody></table> Benchmark 1 — GPU-matrixmultiplikation (rå TFLOPS)</h2> En enkelt 4096×4096 tæt matmul, 20 tids-kørsler efter 5 opvarmningskørsler. Synkroniseret før og efter for at ekskludere kernel launch overhead. Dette er en proxy for rå tensor-beregningsgennemstrømning</strong> — loftet alt andet løber imod.</p> Enhed</th> dtype</th> ms / kørsel</th> TFLOPS</th></tr></thead> i5-13400F CPU</td> float32</td> 237,8 ms</td> 0,58</td></tr> M1 Pro CPU</td> float32</td> 86,4 ms</td> 1,59</td></tr> M1 Pro MPS</td> float32</td> 35,8 ms</td> 3,84</td></tr> M1 Pro MPS</td> float16</td> 33,0 ms</td> 4,16</td></tr> RTX 4070 Ti CUDA</td> float32</td> 4,9 ms</td> 28,3</td></tr> RTX 4070 Ti CUDA</td> float16</td> 1,8 ms</strong></td> 75,3</strong></td></tr> RTX 4070 Ti CUDA</td> bfloat16</td> 1,8 ms</td> 74,9</td></tr> </tbody></table> Hvad tallene betyder</h3> M1 Pro MPS float16 → float32 adskiller sig knap (4,16 vs 3,84 TFLOPS).</strong> M1 GPU’en har ikke dedikerede fp16 tensor cores som NVIDIA. Begge præcisioner kører igennem den samme hardware; fp16-stien sparer noget hukommelsesbåndbredde men vinder lidt beregning.</p> RTX 4070 Ti float16 → 75 TFLOPS — et 18× spring over M1 og et 2,7× spring over sin egen float32.</strong> Dette er tensor core-effekten. NVIDIAs Ada Lovelace-generation (RTX 40xx) har 4. generation tensor cores der opererer nativt på fp16/bf16 matrix-felter og når ca. 4× gennemstrømningen af fp32 CUDA-kernerne på den samme chip. PyTorch router torch.float16</code> matmul igennem dem automatisk.</p> M1 Pro CPU slår Intel i5-13400F CPU med 2,7×</strong> trods begge med 8 aktive tråde. M1 bruger AMX (Apple Matrix Extensions)</strong> — dedikerede matrix-multiplikationsenheder i hver CPU-kerne, separate fra NEON SIMD. PyTorches macOS-backend router float32-matmul igennem dem automatisk. Intel i5’en bruger AVX2 (256-bit SIMD ombrugt til matmul), som er generel brug og markant mindre effektivt til tæt matrixarbejde.</p> Benchmark 2 — LLM-inferens (tokens / sekund, ollama)</h2> Fast 300-token genereringsopgave, temperatur=0, målt som eval_count / eval_duration</code> fra ollama API-svaret (ekskluderer prompt-eval-tid, som rapporteres separat). Prompten beder om en detaljeret forklaring af transformer-internals for at sikre at modellen genererer tæt, varieret output.</p> Model</th> Størrelse</th> M1 Pro tok/s</th> RTX 4070 Ti tok/s</th> RTX / M1</th></tr></thead> minicpm-v4.6</td> 1,6 GB</td> 95,3</td> 278,9</td> 2,9×</strong></td></tr> qwen3.5</td> 6,6 GB</td> 20,3</td> 73,5</td> 3,6×</strong></td></tr> gemma4:12b</td> 7,6 GB</td> —</td> 49,1</td> —</td></tr> </tbody></table> Prompt-eval (tid til første token): M1 Pro 25ms / 115ms; RTX 4070 Ti 9ms / 22ms / 42ms for de tre modeller.</em></p> Båndbredde-historien</h3> Rå beregningsgabet er 18×. LLM-gennemstrømningsgabet er kun 3–4×. Hvorfor?</p> LLM-dekodning ved batch=1 er hukommelsesbåndbredde-begrænset, ikke beregnings-begrænset.</strong> Hvert genereret token kræver at indlæse hele sættet af modelvægte fra VRAM (eller unified memory) én gang per forward pass. Beregningen per byte er lav. GPU’en bruger næsten al sin tid på at flytte data, ikke multiplicere.</p> Det relevante tal er hukommelsesbåndbredde</strong>:</p> RTX 4070 Ti: ~504 GB/s (GDDR6X, dedikeret VRAM-bus)</li> M1 Pro: ~200 GB/s (LPDDR5X, delt CPU/GPU)</li> </ul> Båndbredde-forhold: 2,5×</strong> — som matcher LLM-gennemstrømningsforholdet på 2,9–3,6× næsten præcist. M1 er langsommere fordi den har mindre hukommelsesbåndbredde, ikke fordi dens GPU er 18× svagere. Til LLM-inferens ved små batch-størrelser er det hukommelsesbåndbredde du reelt køber.</p> Unified memory-fordelen</h2> M1 Pro’s GPU har adgang til alle 16 GB</strong> unified memory. En RTX 4070 Ti med 12 GB dedikeret VRAM rammer en hård grænse: modeller større end ~11 GB fp16 passer ikke og falder tilbage til langsomt system-RAM via PCIe, hvilket kollapser gennemstrømningen.</p> Modelstørrelse (fp16)</th> M1 Pro 16GB</th> RTX 4070 Ti 12GB</th></tr></thead> 1–3B (~2–6 GB)</td> Kører hurtigt</td> Kører hurtigt</td></tr> 7B (~14 GB)</td> Kører hurtigt</td> Passer stramt; passer måske ikke</td></tr> 7B kvantiseret q4 (~4 GB)</td> Hurtigt</td> Hurtigt</td></tr> 13B kvantiseret q4 (~8 GB)</td> Hurtigt</td> Hurtigt</td></tr> 30B kvantiseret q4 (~18 GB)</td> Passer ikke</td> Passer ikke</td></tr> </tbody></table> For det almindelige use case — en kvantiseret 7B- eller 13B-model — fungerer begge maskiner komfortabelt. M1 Pro’s unified memory lader den indlæse en ukvantiseret 7B-model i fp16 der ville overløbe en 12GB RTX; RTX kører den samme model kvantiseret til q4 hurtigere samlet set.</p> Hvad 95 vs 279 tok/s faktisk føles som</h2> minicpm-v4.6 ved 95 tok/s på M1 Pro producerer tokens hurtigere end nogen læser. qwen3.5 ved 20 tok/s på M1 Pro er grænsen — man ser ord dukke op men det føles lidt langsomt. På RTX ved 74 tok/s er qwen3.5 komfortabelt.</p> Til interaktiv brug</strong>: 20–30 tok/s er gulvet for hvad der føles acceptabelt. Begge maskiner klarer det på den lille model; kun RTX klarer det komfortabelt på 6,6GB-modellen.</p> Til en batch-transskriptions- eller resumé-pipeline</strong> der kører kontinuerligt vinder RTX klart — 279 vs 95 tok/s betyder 3× gennemstrømningen med den samme model. Den danske voicelog-pipeline</a> der bruger Claude Code-subagenter som resumélag kører præcis denne slags vedvarende batch-arbejdsbyrde; en RTX 4070 Ti ville køre den samme arbejdsbyrde på en tredjedel af clock-tiden.</p> Strømforbrug</h2> Ingen instrumenter var tilkoblet for denne kørsel, men nominel TDP giver størrelsesordenen:</p> </th> Tomgang</th> Fuld GPU-belastning</th></tr></thead> M1 Pro MacBook Pro</td> ~5 W</td> ~25–30 W</td></tr> RTX 4070 Ti (kort alene)</td> ~15 W</td> ~200 W</td></tr> </tbody></table> M1 vinder afgørende på effektivitet. Ved 95 tok/s for ~25W og 279 tok/s for ~200W leverer RTX 2,9× ydelsen til 7–8× strømmen</strong> — så M1 er 2,5× mere effektiv per watt</strong> til LLM-inferens.</p> Hvilken maskine til lokal AI?</h2> Use case</th> Vælg</th></tr></thead> Interaktiv lokal assistent (7B–13B kvantiseret)</td> Begge — RTX hurtigere, M1 roligere og mere effektiv</td></tr> Vedvarende batch-inferens (transskribering, resuméer)</td> RTX 4070 Ti</strong> — 3× gennemstrømning</td></tr> Indlæsning af store fp16-modeller uden kvantisering</td> M1 Pro</strong> — unified memory, ingen VRAM-grænse</td></tr> Træning eller fine-tuning (LoRA)</td> RTX 4070 Ti</strong> — tensor cores, CUDA-økosystem</td></tr> Always-on hjemmeserver (elregning betyder noget)</td> M1 Pro</strong> — ~7–8× lavere GPU-strømforbrug</td></tr> Numerisk ML (CV, embeddings, matmul-tungt)</td> RTX 4070 Ti</strong> — 7–18× hurtigere</td></tr> </tbody></table> Benchmarks kørt på personligt hardware, juni 2026. LLM-gennemstrømning afhænger kraftigt af modelkvantisering, kontekstlængde og systembelastning — behandl disse tal som størrelsesordenssammenligninger, ikke absolutte specifikationer.</em></p> Ollama — komplet guide til lokal AI (2026) 2026-06-22T00:00:00+00:00 Ollama</strong> lader dig køre store sprogmodeller lokalt med én kommando: ollama run llama3.2</code>. Ingen API-nøgle, ingen abonnement, ingen data der forlader din maskine. Denne guide tager dig fra installation til færdig opsætning — inkl. REST API, Python og performance-tricks.</p> Installation</h2> Mac</h3> brew install ollama </code></pre> Start serveren:</p> ollama serve </code></pre> Eller som baggrundstjeneste der starter automatisk ved login:</p> brew services start ollama </code></pre> Linux</h3> curl -fsSL https://ollama.com/install.sh \| sh </code></pre> Installationen sætter Ollama op som en systemd</code>-service der starter automatisk. Tjek status med:</p> systemctl status ollama </code></pre> Windows</h3> Download installationsfilen fra ollama.com</a> — den sætter sig op som en bakke-app og starter automatisk ved login.</p> Første model</h2> Pull og kør en model med én kommando:</p> ollama run llama3.2:3b </code></pre> Ollama downloader modellen første gang (~2 GB), cacher den i ~/.ollama/models/</code>, og åbner en interaktiv chat. /bye</code> afslutter.</p> For at downloade uden at åbne chat:</p> ollama pull qwen3.5 </code></pre> Hvilken model skal du vælge?</h2> Model</th> Størrelse</th> RAM/VRAM</th> Hvad den er god til</th></tr></thead> llama3.2:1b</code></td> 1.3 GB</td> 2 GB</td> Hurtigste option — god til klassificering, korte svar</td></tr> llama3.2:3b</code></td> 2.0 GB</td> 3 GB</td> Bedste startpunkt</strong> — kompetent, kører overalt</td></tr> llama3.1:8b</code></td> 4.9 GB</td> 6 GB</td> Solid alsidig model, god til kode og tekst</td></tr> qwen3.5</code></td> 6.6 GB</td> 8 GB</td> Anbefalet</strong> — 9.7B, 262k kontekst, stærk på dansk</td></tr> gemma4:12b</code></td> 7.6 GB</td> 9 GB</td> Googles model — meget god til instruktioner</td></tr> phi4:14b</code></td> 9.1 GB</td> 11 GB</td> Microsofts kompakte model, god til ræsonnering</td></tr> llama3.1:70b</code></td> 43 GB</td> 48 GB</td> Kraftfuld — kræver server med meget VRAM/RAM</td></tr> minicpm-v4.6</code></td> 1.6 GB</td> 2 GB</td> Multimodal — kan se billeder</td></tr> </tbody></table> Tommelfingerregel:</strong> vælg den største model der passer i din GPU’s VRAM. Modellen skal helst</em> ligge helt i VRAM — flyder den over til RAM, falder hastigheden dramatisk.</p> Søg og find alle tilgængelige modeller:</p> ollama search llama </code></pre> CLI cheat sheet</h2> # Kør interaktiv chat ollama run qwen3.5 # Kør med system-prompt fra kommandolinjen ollama run llama3.2:3b "Forklar TCP/IP i tre sætninger" # Pipe input ind cat artikel.txt \| ollama run qwen3.5 "Opsummer dette" # List downloadede modeller ollama list # Vis modeldetaljer (parametre, kvantisering, kontekstlængde) ollama show qwen3.5 # Slet en model ollama rm llama3.2:1b # Kopiér og omdøb en model ollama cp qwen3.5 mit-projekt # Vis kørende modeller og VRAM-brug ollama ps </code></pre> REST API</h2> Ollama eksponerer en HTTP-API på localhost:11434</code>. Du kan bruge den direkte fra terminalen eller fra ethvert programmeringssprog.</p> Generér tekst</h3> curl http://localhost:11434/api/generate -d '{ "model": "qwen3.5", "prompt": "Hvad er forskellen mellem TCP og UDP?", "stream": false }' </code></pre> Vigtige felter i svaret:</p> { "response": "TCP er forbindelsesorienteret...", "eval_count": 142, "eval_duration": 1923000000, "prompt_eval_duration": 215000000 } </code></pre> eval_count / (eval_duration / 1e9)</code> giver tokens per sekund.</p> Chat (med historik)</h3> curl http://localhost:11434/api/chat -d '{ "model": "qwen3.5", "messages": [ {"role": "system", "content": "Du er en hjælpsom dansk assistent."}, {"role": "user", "content": "Hvad er hovedstaden i Danmark?"} ], "stream": false }' </code></pre> Streaming</h3> Sæt "stream": true</code> (standard) for at få tokens løbende:</p> curl http://localhost:11434/api/generate -d '{ "model": "qwen3.5", "prompt": "Skriv et digt om terminal-programmering", "stream": true }' \| while IFS= read -r line; do echo "$line" \| python3 -c "import json,sys; d=json.load(sys.stdin); print(d.get('response',''), end='', flush=True)" done </code></pre> Liste over downloadede modeller</h3> curl http://localhost:11434/api/tags </code></pre> Nyttige options</h3> curl http://localhost:11434/api/generate -d '{ "model": "qwen3.5", "prompt": "...", "stream": false, "options": { "temperature": 0.7, "num_predict": 500, "num_ctx": 8192, "top_p": 0.9, "seed": 42 } }' </code></pre> Option</th> Standard</th> Hvad det gør</th></tr></thead> temperature</code></td> 0.8</td> Kreativitet: 0 = deterministisk, 1+ = mere tilfældig</td></tr> num_predict</code></td> -1 (ubegrænset)</td> Max tokens at generere</td></tr> num_ctx</code></td> modelens standard</td> Kontekstvindue (tokens)</td></tr> seed</code></td> tilfældig</td> Fast seed → reproducerbare svar</td></tr> top_p</code></td> 0.9</td> Nucleus sampling</td></tr> </tbody></table> Python</h2> Ollama’s API er simpel nok til at bruge med urllib</code> — ingen ekstra pakker nødvendigt:</p> import urllib.request, json def ollama(prompt, model="qwen3.5", system=None): messages = [] if system: messages.append({"role": "system", "content": system}) messages.append({"role": "user", "content": prompt}) payload = json.dumps({ "model": model, "messages": messages, "stream": False, "options": {"temperature": 0} }).encode() req = urllib.request.Request( "http://localhost:11434/api/chat", data=payload, headers={"Content-Type": "application/json"} ) with urllib.request.urlopen(req) as resp: return json.load(resp)["message"]["content"] # Brug svar = ollama("Forklar forskellen mellem list og tuple i Python") print(svar) </code></pre> Foretrækker du en dedikeret pakke:</p> pip install ollama </code></pre> import ollama svar = ollama.chat( model="qwen3.5", messages=[{"role": "user", "content": "Hvad er Rust?"}] ) print(svar["message"]["content"]) </code></pre> Modelfile — tilpas en model</h2> En Modelfile</code> lader dig oprette en ny model baseret på en eksisterende — med fast system-prompt, temperatur og parametre.</p> Opret filen Modelfile</code>:</p> FROM qwen3.5 SYSTEM """ Du er en præcis dansk teknisk assistent. Svar altid på dansk. Vær kortfattet. Vis kodeeksempler når relevant. """ PARAMETER temperature 0.3 PARAMETER num_ctx 16384 </code></pre> Byg og brug den:</p> ollama create dansk-assistent -f Modelfile ollama run dansk-assistent "Hvad er en hash-tabel?" </code></pre> List dine brugerdefinerede modeller:</p> ollama list </code></pre> Du kan dele Modelfiles med kolleger — de puller bare base-modellen og kører ollama create</code>.</p> Performance-tips</h2> Flash Attention (anbefalet)</h3> Reducerer VRAM-brug og øger hastighed på lange kontekster:</p> OLLAMA_FLASH_ATTENTION=1 ollama serve </code></pre> På Mac via Homebrew, tilføj til ~/.zshrc</code>:</p> export OLLAMA_FLASH_ATTENTION=1 </code></pre> KV-cache kvantisering</h3> Halverer næsten VRAM-forbruget til kontekst-cachen, med minimal kvalitetstab:</p> OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve # halvt VRAM, ingen synlig forskel OLLAMA_KV_CACHE_TYPE=q4_0 ollama serve # endnu mindre, let kvalitetstab </code></pre> Parallelle requests</h3> Ollama håndterer som standard én request ad gangen. Til serverbrug:</p> OLLAMA_NUM_PARALLEL=4 ollama serve # 4 samtidige requests OLLAMA_MAX_LOADED_MODELS=2 ollama serve # hold 2 modeller i VRAM </code></pre> Se hvad der kører</h3> ollama ps # NAME ID SIZE PROCESSOR UNTIL # qwen3.5:latest ... 7.9 GB 100% GPU 4 minutes from now </code></pre> Modeller unloades automatisk efter 5 minutters inaktivitet. Skift timeout:</p> OLLAMA_KEEP_ALIVE=30m ollama serve # hold indlæst i 30 min OLLAMA_KEEP_ALIVE=-1 ollama serve # hold indlæst for evigt </code></pre> Som server på netværket</h2> Som standard lytter Ollama kun på localhost. Åbn for netværksadgang:</p> OLLAMA_HOST=0.0.0.0:11434 ollama serve </code></pre> Brug Tailscale</strong> til at eksponere din GPU-server sikkert på dit private netværk uden at åbne for internet:</p> # På serveren med RTX 4070 Ti: OLLAMA_HOST=0.0.0.0:11434 ollama serve # Fra din Mac via Tailscale: OLLAMA_HOST=gpu-box:11434 ollama run qwen3.5 # eller direkte via API: curl http://gpu-box:11434/api/generate -d '{"model":"gemma4:12b","prompt":"..."}' </code></pre> På Linux med systemd, tilføj env vars i service-filen:</p> sudo systemctl edit ollama </code></pre> [Service] Environment="OLLAMA_HOST=0.0.0.0:11434" Environment="OLLAMA_FLASH_ATTENTION=1" Environment="OLLAMA_KV_CACHE_TYPE=q8_0" </code></pre> sudo systemctl restart ollama </code></pre> OpenAI-kompatibelt API</h2> Ollama understøtter OpenAI’s API-format, så eksisterende kode der bruger openai</code>-pakken kører uden ændringer:</p> from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama", # kræves af klienten, ignoreres af Ollama ) response = client.chat.completions.create( model="qwen3.5", messages=[{"role": "user", "content": "Hvad er en linked list?"}] ) print(response.choices[0].message.content) </code></pre> Hvad koster det at køre?</h2> Ingenting — bortset fra strøm. En 7B-model på en RTX 4070 Ti (200W under load) koster ca.:</p> Brug</th> Strøm</th> Pris (3 kr/kWh)</th></tr></thead> 1 times chat (~50 req)</td> ~0,1 kWh</td> ~0,30 kr</td></tr> 1 dags batch-transskription</td> ~0,5 kWh</td> ~1,50 kr</td></tr> GPT-4o via API (samme mængde)</td> —</td> ~50–200 kr</td></tr> </tbody></table> På M1 Pro (25W) er strømomkostningen nærmest symbolsk.</p> Nyttige links</h2> ollama.com/library</a> — alle tilgængelige modeller</li> github.com/ollama/ollama</a> — kildekode og issues</li> API-reference: http://localhost:11434</code> når Ollama kører</li> </ul> Se også M1 Pro vs RTX 4070 Ti — GPU og LLM benchmarks</a> for konkrete tal på, hvad de to platforme leverer.</p> </blockquote> Rust vs Go vs C på Apple Silicon og Linux — benchmarks på rigtig hardware (2026) 2026-06-22T00:00:00+00:00 Kort fortalt —</strong> Fire benchmarks på to maskiner: Apple M1 Pro</strong> (arm64, macOS 26.6, clang 21) og Intel i5-13400F</strong> (x86_64, Ubuntu 24.04, gcc 13). På M1 matcher Rust C inden for støj på alle tests. På Linux x86 slår gcc rustc på rekursiv fib</strong> (1,5×) og Go’s fib falder til 2,9× langsommere end C</strong> — et meget større gab end på arm64. Den største overraskelse: Rust’s parallel sum er 2,8× hurtigere end C pthreads på x86</strong>, sandsynligvis fordi LLVM folder heltalsrækken til en lukket formel som løkken aldrig rent faktisk kører.</p> Opsætning</h2> </th> M1 Pro (arm64)</th> i5-13400F (x86_64)</th></tr></thead> Maskine</strong></td> Apple MacBook Pro</td> Desktop-PC</td></tr> RAM</strong></td> 16 GB</td> 125 GB</td></tr> OS</strong></td> macOS 26.6 (Sequoia)</td> Ubuntu 24.04</td></tr> C-compiler</strong></td> Apple clang 21.0, -O3 -march=native</code></td> GCC 13.3, -O3 -march=native</code></td></tr> Go</strong></td> 1.26.4 darwin/arm64</td> 1.22.4 linux/amd64</td></tr> Rust</strong></td> 1.96.0</td> 1.96.0</td></tr> Rust-flag</strong></td> -C opt-level=3 -C target-cpu=native</code></td> -C opt-level=3 -C target-cpu=native</code></td></tr> </tbody></table> Hvert benchmark kørtes tre gange; tabellerne nedenfor viser medianen af kørsel 2–3.</p> De fire benchmarks</h2> 1 — Primtalssold (primtal op til 10.000.000)</h3> Fladt bool-array-sold: skrive-tungt sekventiel hukommelsesadgang, letgrebet indre løkke. God proxy for hukommelsesbåndbredde-begrænset kode.</p> 2 — Rekursiv Fibonacci (n = 47)</h3> Ingen heap-allokering, ingen løkker — ~2,97 milliarder stakrammer. Måler rå kald-dispatch, grenforudsigelse og hvor aggressivt hver compiler inliner/optimerer dyb rekursion.</p> 3 — Matrixmultiplikation (512 × 512, f64, i-k-j løkkerækkefølge)</h3> Cache-venlig løkkerækkefølge men stadig en tæt FP-akkumulering i den indre løkke. Her betyder auto-vektorisering og eliminering af grænsecheck mest.</p> 4 — Parallel sum (100.000.000 heltal, 8 tråde)</h3> 8 POSIX-tråde (C), goroutines (Go) eller std::thread</code> (Rust), der hver summerer en partition af 0..100_000_000</code>. Tester tråd-spawn-overhead og hvor smart hver compiler håndterer den indre sum.</p> Resultater: Apple M1 Pro (arm64, clang 21, macOS)</h2> Benchmark</th> C</th> Go 1.26</th> Rust 1.96</th></tr></thead> Sold (10M primtal)</td> 13,3 ms</td> 19,3 ms</td> 12,3 ms</strong></td></tr> Fib(47) rekursiv</td> 8,86 s</td> 9,84 s</td> 8,91 s</td></tr> Matrixmultiplikation 512²</td> 24,7 ms</td> 80,2 ms</td> 24,1 ms</strong></td></tr> Parallel sum 100M</td> 3,0 ms</td> 10,7 ms</td> 3,4 ms</td></tr> </tbody></table> Resultater: Intel i5-13400F (x86_64, gcc 13, Linux)</h2> Benchmark</th> C</th> Go 1.22</th> Rust 1.96</th></tr></thead> Sold (10M primtal)</td> 25,7 ms</td> 34,3 ms</td> 27,6 ms</td></tr> Fib(47) rekursiv</td> 4,06 s</td> 11,86 s</strong></td> 6,02 s</td></tr> Matrixmultiplikation 512²</td> 22,5 ms</td> 106,7 ms</td> 28,3 ms</td></tr> Parallel sum 100M</td> 3,4 ms</td> 8,7 ms</td> 1,2 ms</strong></td></tr> </tbody></table> Median af 3 kørsler, kørsel 2 brugt. 2026-06-22.</em></p> Hastighed relativt til C, begge maskiner</h2> Benchmark</th> Go/C (M1)</th> Go/C (i5)</th> Rust/C (M1)</th> Rust/C (i5)</th></tr></thead> Sold</td> 1,45×</td> 1,33×</td> 0,92×</td> 1,07×</td></tr> Fib(47)</td> 1,11×</td> 2,92×</strong></td> 1,01×</td> 1,48×</td></tr> Matrixmultiplikation</td> 3,24×</td> 4,74×</strong></td> 0,98×</td> 1,26×</td></tr> Parallel sum</td> 3,57×</td> 2,56×</td> 1,13×</td> 0,35×</strong></td></tr> </tbody></table> Tre ting der er værd at forklare</h2> 1 — Go’s fib kollapser på x86</h3> På M1 var Go’s fib(47) 11% langsommere end C — i praksis det samme. På i5’en er det 2,9× langsommere</strong>. Samme Go-version, samme algoritme. Forskellen er compiler-backend’en: Go’s arm64-kodegeneration håndterer dybe rekursive kaldkæder mere effektivt end dens amd64-kodegeneration. Dette er et kendt kvalitetsgab; Go’s x86-backend er generelt mindre moden end arm64-backendet til rekursionstunge mønstre.</p> 2 — gcc slår rustc på rekursiv fib</h3> På M1 (clang mod rustc, begge bruger LLVM) tog fib ~8,9s i begge sprog — identisk. På Linux producerede gcc 4,06s mens rustc producerede 6,02s — gcc er 1,5× hurtigere</strong>. GCC’s optimizer anvender mere aggressiv tail-rekursion og inlining-heuristikker for dette specifikke mønster på x86. Det er en påmindelse om at “Rust bruger LLVM” ikke betyder at det altid vinder over gcc; GCC har 30+ år af x86-optimeringskunst bag sig.</p> 3 — Rust’s parallel sum er 2,8× hurtigere end C på x86</h3> Rust-trådens krop er (start..end).sum::<u64>()</code>. LLVM genkender en sum af en sammenhængende heltalsrækkevidde som en aritmetisk rækkeformel</strong> og erstatter løkken med en lukket beregning n(n+1)/2</code> — O(1), uanset rækkeviddens størrelse. GCC med den manuelle for (i = start; i < end; i++) s += i;</code>-løkke anvender SIMD-vektorisering men laver ikke spring til lukket form. Resultat: Rust’s otte tråde udfører hver én multiplikation; C’s otte tråde summerer hver 12,5M heltal. 2,8×-forskellen er udelukkende en compiler-optimeringsforkel, ikke en sprogforskel. (På arm64 var denne effekt mindre fordi Apple clang også anvender noget af denne optimering.)</p> Binærstørrelse og kompileringstid</h2> </th> C (macOS)</th> C (Linux)</th> Go (macOS)</th> Go (Linux)</th> Rust (macOS)</th> Rust (Linux)</th></tr></thead> Binærstørrelse (sold)</td> 33 KB</td> 16 KB</td> 2,5 MB</td> 1,9 MB</td> 431 KB</td> 4,3 MB</strong></td></tr> Kold kompilering (sold)</td> 96 ms</td> 54 ms</td> 319 ms</td> 193 ms</td> 660 ms</td> 134 ms</td></tr> </tbody></table> Rust-binæren der er 4,3 MB på Linux mod 431 KB på macOS</strong> er den mest slående størrelsesforkel. På macOS linker Rust mod system-dylibs for dele af standardbiblioteket og holder binæren lille. På Linux linker Rust alt statisk, hvilket producerer en større men fuldt selvstændig binær uden system-biblioteksafhængighed — en reel fordel til containere.</p> Kompileringstider vender: Rust er 134ms på Linux mod 660ms på macOS</strong> for en enkelt fil. LLVM’s x86_64-backend er markant hurtigere til at udsende kode end dens arm64-backend.</p> Anno 2026: hvor lever hvert sprog?</h2> C</strong> er stadig referencepunktet og stadig hurtigst på rå rekursivt arbejde når gcc’s optimizer er involveret. I 2026 er det ikke et førstehåndsvalg til nye projekter medmindre du skriver kernekode, embedded firmware eller FFI-klister — men compiler-kunsten akkumuleret siden 1972 er reel.</p> Go</strong> ramte 1.0 i 2012 med en klar tese: gør det at skrive netværkstjenester lige så hurtigt at udvikle som Python, mens man kører med effektiviteten af et kompileret sprog. Det har i høj grad lykkedes. Hvad det betaler for det: GC’en tilføjer latensvarians, og performance-loftet er lavere end Rust eller C for beregningstunge løkker. fib-resultatet på x86 afslører også at Go’s optimizer har reelle kvalitetsgab på visse mønstre — den er tunet til hvad Go-kode faktisk ligner (interfaces, kanaler, HTTP-handlere), ikke trærekursion.</p> Rust</strong> ramte 1.0 i 2015 og har brugt et årti på at bevise at hukommelsessikkerhed uden GC er opnåeligt i stor skala. I 2026 accepterer Linux-kernen Rust til drivere (siden 6.1), Firefox og Chromium erstatter gradvist C++ med det, og ISRG omskriver kritisk netværksinfrastruktur i det. Den lukkede formel-sum-optimering ovenfor er et godt eksempel på hvad “zero-cost abstractions” betyder i praksis: at skrive idiomatisk Rust lader compileren anvende transformationer som en manuel C-løkke ikke kan udløse.</p> Pick-one-guide</h2> Du vil…</th> Vælg</th></tr></thead> Skrive en Linux-driver eller kernemodul</td> C</strong> (eller Rust hvis subsystemet accepterer det)</td></tr> Bygge en mikrotjeneste eller CLI-værktøj hurtigt</td> Go</strong> — tooling + goroutines + hurtig iteration</td></tr> Skrive sikkerhedskritisk systemkode</td> Rust</strong> — borrowchecker, ingen GC, ingen UB</td></tr> Optimere en varm numerisk indre løkke</td> C</strong> eller Rust</strong> — SIMD, ingen grænsecheck, fuld LLVM</td></tr> Levere en statisk binær til en container</td> Go</strong> (statisk som standard) eller Rust (musl</code>)</td></tr> Målrette arm64-performance</td> Rust</strong> ≈ C, bedre end Go</td></tr> Målrette x86-rekursiv kode</td> C med gcc</strong> vinder; Rust konkurrencedygtig; Go halter</td></tr> </tbody></table> Benchmarks kørt på personligt hardware; dine tal vil variere med CPU, OS-indstillinger og compiler-flag. Koden er fire enkelt-fils programmer, ingen eksterne afhængigheder. Alle compilere kaldt med fulde optimeringsflag som vist ovenfor.</em></p> BIN/IIN-opslag: kort-præfiksernes intervaller og hvordan du slår et op (2026) 2026-06-10T00:00:00+00:00 Kort fortalt —</strong> Et korts første cifre — BIN</strong> (Bank Identification Number) / IIN</strong> (Issuer Identification Number) — identificerer netværket</strong> og udstederen</strong>. Du kan læse netværket</em> direkte ud af præfiksintervallerne (tabel nedenfor). Udsteder/bank/land</em> kræver en BIN-database</strong> — der er ingen formel for det. Denne side giver dig IIN-intervaltabellen</strong>, 6-vs-8-ciffer-forbeholdet</strong> og de tre måder at slå et BIN op på</strong> (i hånden, via side/API, programmatisk).</p> Baggrundslæsning på bloggen: hvorfor et 6-ciffers BIN nu er flertydigt</a> og historien bag binlist.net og iinlist.com</a>.</p> </blockquote> Hvad et BIN/IIN er</h2> Kortnummeret (PAN, primary account number) er struktureret: de første cifre er IIN’et</strong>, der identificerer den udstedende institution og netværket; resten er det individuelle kontonummer, med et afsluttende Luhn-kontrolciffer</strong>. “BIN” er det daglige branchebegreb; “IIN” er det formelle begreb i ISO/IEC 7812</strong>. IIN’et var 6 cifre</strong> i årtier og er udvidet til 8</strong> for de fleste netværk — se 8-ciffer-indlægget</a>.</p> IIN-præfiksintervaller pr. netværk</h2> Hvad du kan</em> bestemme ud fra præfikset alene — hvilket netværk der udstedte kortet:</p> Netværk</th> IIN-præfiksinterval(ler)</th> PAN-længde</th></tr></thead> Visa</strong></td> 4</code></td> 13, 16, 19</td></tr> Mastercard</strong></td> 51</code>–55</code>, 2221</code>–2720</code></td> 16</td></tr> American Express</strong></td> 34</code>, 37</code></td> 15</td></tr> Discover</strong></td> 6011</code>, 644</code>–649</code>, 65</code>, 622126</code>–622925</code></td> 16–19</td></tr> Diners Club Intl</strong></td> 36</code>, 300</code>–305</code>, 3095</code>, 38</code>–39</code></td> 14–19</td></tr> JCB</strong></td> 3528</code>–3589</code></td> 16–19</td></tr> UnionPay</strong></td> 62</code>, 81</code></td> 16–19</td></tr> Maestro</strong></td> 50</code>, 56</code>–69</code>, 6304</code>, 6759</code>, 676770</code>, 676774</code></td> 12–19</td></tr> RuPay</strong></td> 60</code>, 6521</code>, 6522</code></td> 16</td></tr> Mir</strong></td> 2200</code>–2204</code></td> 16</td></tr> Troy</strong></td> 9792</code></td> 16</td></tr> </tbody></table> Bemærk: intervaller kan overlappe i kanterne (f.eks. nogle 62</code> UnionPay vs. 622126</code>–622925</code> Discover-cobadging), og 50</code>/56</code>–69</code> for Maestro er bredt og kolliderer med andre — hvilket er præcis derfor, opløsning på udstederniveau kræver en database, ikke en præfiksregel.</p> Hvad du ikke</em> kan se ud fra præfikset</h2> Der er ingen formel</strong>, der oversætter et præfiks til et banknavn, land eller debit/kredit-flag. Den kobling ligger i en vedligeholdt BIN-database</strong> bygget af netværksbulletiner og observerede kort. Så:</p> Netværk</strong> → kan læses ud af tabellen ovenfor. ✅</li> Udstederbank, land, korttype, produkt, prepaid/debit/kredit</strong> → kun databaseopslag. ❌ i hånden.</li> </ul> Tre måder at slå et BIN op på</h2> 1. I hånden (kun netværk)</h3> Tag de første cifre og match dem mod tabellen ovenfor. Godt nok, når alt du har brug for er “er det Visa eller Mastercard?”.</p> 2. På en opslagsside / gratis API</h3> For detaljer på udstederniveau, brug en BIN-opslagstjeneste. Det velkendte gratis valg er binlist.net</strong>, som blotlægger et JSON-API:</p> curl https://lookup.binlist.net/45717360 </code></pre> { "scheme": "visa", "type": "debit", "brand": "Visa Classic", "bank": { "name": "Example Bank", "country": "..." }, "country": { "name": "United Kingdom", "alpha2": "GB" } } </code></pre> Det er rate-limited</strong> (en håndfuld forespørgsler i timen) og bedst til lejlighedsvise opslag. Til volumen, 8-ciffers granularitet og pålidelighed vil du have en licenseret database — iinlist.com</strong> er det kommercielle valg bygget til netop dette. (Baggrund: hvordan begge opstod</a>.)</p> Send kun BIN’et — de første 6-8 cifre — aldrig et fuldt kortnummer</strong> til et tredjepartsopslag. Præfikset er alt, et opslag behøver, og fulde PAN’er er følsomme (PCI) data.</p> 3. Programmatisk</h3> Til mere end det lejlighedsvise tjek: validér og normalisér først, slå så op:</p> # normalisér: fjern mellemrum, tag de første 8 cifre som BIN bin=$(echo "4571 7360 1234 5678" \| tr -dc '0-9' \| cut -c1-8) curl -s "https://lookup.binlist.net/$bin" </code></pre> Et hurtigt Luhn</strong>-gyldighedstjek, før du gemmer eller slår noget op (POSIX-shell):</p> luhn() { # returnerer 0 hvis nummeret består Luhn-tjekket echo "$1" \| tr -dc '0-9' \| rev \| awk '{ s=0; for(i=1;i<=length;i++){d=substr($0,i,1); if(i%2==0){d=2; if(d>9)d-=9}; s+=d} exit (s%10!=0) }' } luhn "4571736012345678" && echo gyldig \|\| echo ugyldig </code></pre> Til BIN-matching i produktion: indlæs en licenseret BIN-fil i din egen tabel, og key på 8 cifre</strong> med fallback til 6 med et lav-tillids-flag.</p> Opsummering</h2> BIN/IIN’et</strong> er kortnummerets første cifre — netværk + udsteder</strong>; 6 cifre historisk, 8 nu</strong>.</li> Du kan læse netværket</strong> ud af præfiksintervallerne</a>; udsteder/bank/land kræver en database</strong>.</li> Slå op: i hånden</strong> (netværk), en side/API</strong> som binlist.net (gratis, rate-limited) eller iinlist.com</strong> (kommerciel, 8-ciffer), eller programmatisk</strong>.</li> Send kun de første 6-8 cifre</strong>, aldrig et fuldt PAN, til noget tredjepartsopslag.</li> Foretræk 8-ciffers</strong> matching — se hvorfor 6 cifre nu er flertydigt</a>.</li> </ul> Transskribering af 33.000 danske voicelogs på hjemme-GPU'er — den lokale pipeline (2026) 2026-06-10T00:00:00+00:00 Kort fortalt —</strong> Forretningstelefonsamtaler var blevet optaget i over et år: ~33.000 danske mp3-filer, ~570 timer, 32 kbps telefonkvalitet</strong>. Opgaven var at transskribere det hele, navngive talerne, resumere pr. opkald / pr. dag / pr. uge, gøre det browsbart — og gøre det lokalt, uden LLM-API</strong>. Resultatet er en pipeline, der kører to ASR-modeller og fusionerer dem med Claude</strong>, identificerer talere fra metadata før noget lyd afkodes</strong>, heler sig selv over to GPU’er</strong>, og bruger Claude Code-subagenter som resumélag</strong> i stedet for et API. Her er hele bygget, og hvad det lærer om en kundeservicefunktion.</p> Den voksne efterfølger til at køre Whisper lokalt i stedet for et cloud-Speech-API</a>. Samme instinkt — hold lyden på din egen boks — i 33.000-fil-skala.</p> </blockquote> Begynd med at analysere ligene</h2> Mappen indeholdt allerede ni halvfærdige forsøg</strong> på problemet. Før der blev skrevet noget nyt, læste tre agenter alle ni. Tilsammen indeholdt de døde eksperimenter næsten alle de rigtige idéer, det endelige system havde brug for:</p> Ét Python-forsøg (WhisperX + pyannote + Claude-dagsresuméer) var det mest komplette — men havde hardcodede API-nøgler, en engelsk-alignment-bug på dansk lyd og mock-diarisering i den “rigtige” pipeline.</li> Ét havde opdaget nøgletricket: phone-first taleridentifikation</strong> (mere nedenfor) og havde allerede bygget stemmeprofiler.</li> En Go-omskrivning havde en flot service-arkitektur og et SQLite-skema — men alt var stubs</strong>; nul segmenter blev nogensinde gemt. Lektion: byg aldrig skallen, før signalvejen virker.</li> Et benchmark-harness havde allerede sammenlignet seks ASR-modeller</strong> på korpusset.</li> </ul> At syntetisere de ni var langt billigere end at opfinde fra bunden. Lektion ét: analysér ligene først.</strong></p> Modelbenchmarken</h2> Det eksisterende benchmark (på RTX 4070 Ti) plus en frisk sammenligning afgjorde modelvalget:</p> Model</th> Resultat</th></tr></thead> faster-whisper large-v3-turbo</strong></td> Hurtigst — ~37× realtid, 1,8 GB VRAM. God, men glider på støjende dansk.</td></tr> faster-whisper large-v3 (fuld)</strong></td> Mest kohærent på rigtige opkald. ~18× realtid — hurtig nok. Valgt.</strong></td></tr> hviske-v3-conversation</strong> (dansk fine-tune)</td> Fanger danske navne/vendinger, de andre forvansker. Valgt som andet spor.</strong></td></tr> Voxtral</strong></td> Hallucinerede i løkker (1.832 ord for et 117-sekunders opkald), sprog-bleed. Droppet.</strong></td></tr> vibevoice</strong></td> ~6× langsommere end realtid. Droppet.</strong></td></tr> </tbody></table> Den ikke-oplagte beslutning: kør to modeller, ikke én.</strong> large-v3 og hviske fejler forskelligt</strong> — den ene har grammatikken, den anden har de danske navne — så at beholde begge og fusionere dem slår hver for sig.</p> Pipelinen</h2> mp3 → ffmpeg båndpas (200–3400 Hz + let denoise + dynaudnorm) → 16 kHz mono → [A] faster-whisper large-v3 (int8_float16, beam 5, VAD, anti-løkke-guards) → [B] hviske-v3-conversation (dansk fine-tune) ← kun på opkald ≥45 s → ECAPA-TDNN-diarisering (token-fri klyngedeling, 2-taler-prior på lange opkald) → "phone-first" navngivning (filnavn + telefonbog forankrer identiteter; embeddings afgør hvilken klynge der er den gennemgående part; referenceprofiler matcher resten) → SQLite (idempotent: SHA-256-hash + status; dubletter arver tvillingens resultat) pr. dag → Claude-subagent læser BEGGE transskriptioner pr. opkald, fusionerer dem, retter diarisering ud fra kontekst, skriver dagsresuméet (dansk) pr. uge → Claude-subagent syntetiserer 7 dagsresuméer til tråde + en løftetabel web → Flask læser DB'en live (dage, uger, opkald m. audio, søgning, mønstre) </code></pre> Et par beslutninger gjorde sig fortjent:</p> Phone-first taleridentifikation.</strong> Filnavnet bærer tidsstemplet og begge numre; en lille telefonbog oversætter numre til navne. Man kender begge</em> identiteter, før et ord afkodes — lyden skal kun afgøre hvilken stemme der er hvem</em>, ikke hvem de er</em>. Metadata er guld.</strong></li> ffmpeg-båndpas hjælper; DeepFilterNet skader.</strong> Målt: et 50 år gammelt båndpasfilter gjorde støjende opkald mere kohærente gratis; den neurale SOTA-denoiser gav hallucinationer og tabt tale. SOTA er opgaveafhængigt.</strong></li> ECAPA frem for pyannote.</strong> pyannote løb tør for hukommelse ved siden af Whisper på et 12 GB-kort og var for langsom på CPU til 33k filer. Token-fri ECAPA-klyngedeling på GPU’en, med en 2-taler-prior</strong> (et telefonopkald er</em> to-parts), reddede de 79% af lange opkald, der ellers kollapsede til én taler.</li> int8_float16 + udvidelige segmenter</strong> lod begge</strong> modeller sameksistere i ~6–8 GB på 12 GB-kortet.</li> </ul> Resumélaget: Claude Code-subagenter, intet API</h2> Den hårde binding var ingen LLM-API-nøgle</strong>. Så harnesset selv er sprogmodellen: én Claude Code-subagent pr. dag</strong> får begge ASR-spor for hvert opkald, et fælles navneregister og gårsdagens resumé, og skriver dagsresuméet direkte — ~50k–450k tokens pr. dag-agent, intet API-kald i pipelinen, ingen marginalomkostning.</strong></p> Tre små “institutioner” voksede op omkring det:</p> En fusions-instruksfil</strong> — fletregler ([A]’s struktur, [B]’s danske ord), ret diarisering ud fra kontekst (en taler der nævner sit eget navn fastlægger, hvem der taler), spring voicemails over, opfind aldrig indhold, rapportér usikkerhed ærligt.</strong></li> Et fælles, voksende navneregister</strong> — agenterne læser det før skrivning og tilføjer nye afklaringer. Over 60+ dage forener det stavevarianter af samme kontakt til én bekræftet identitet og holder to ens-navngivne personer adskilt. Navnekonsistens over hele korpusset, lag på lag.</li> En ugentlig løftetabel</strong> — hver uges agent fører en “løfter & leverancer”-tabel videre (✅/⏳/❌). En reelt nyttig primitiv (og, som vi skal se, broen til kundeservice).</li> </ul> At køre det over to maskiner</h2> Idempotens gjorde korpusset deleligt midt i kørslen:</p> Maskine 1 (RTX 4070 Ti, 12 GB):</strong> hele dual-model-pipelinen, kronologisk fremad.</li> Maskine 2 (GTX 1060, 6 GB, Pascal):</strong> deployeret over SSH/Tailscale med ét script; tog en senere partition. Kører kun [A]-sporet i int8 (nye CUDA-wheels droppede Pascal, så torch er på CPU mens CTranslate2 driver GPU’en direkte).</li> Merge:</strong> workeren skriver sin egen SQLite; hovedmaskinen henter og merger hvert 15. minut (idempotent — transcribed</code> kan opgraderes til done</code>). Korpusset behandles fra begge ender på én gang.</strong></li> </ul> Fordi hver fil er nøglet på SHA-256-hash + status</strong>, var det harmløst at flytte halvdelen af arbejdet til en anden maskine midt i kørslen. Idempotens er friheden til at fejle.</strong></p> Selvheling, lært på den hårde måde</h2> Lange uovervågede kørsler fejler på kreative måder. Hver fejl fik et permanent modtræk:</p> To transkriptionsprocesser på én GPU</strong> (en forældreløs overlevede en genstart) → gensidig OOM-forgiftning, 756 fejlede rækker. Modtræk: en flock</code>-singleton i supervisoren + auto-drab af forældreløse ved opstart.</li> “Poison file”-myten</strong> — en fil så ud til at crashe processen igen og igen; det var i virkeligheden dual-proces-konflikten. Den kørte fint ved retry. Supervisoren fik retry-én-gang-så-karantæne-logik alligevel.</li> Tavse hæng</strong> — en worker hang i en time på én fil (proces i live, ingen fremdrift). Modtræk: en watchdog der dræber inder-processen efter 20 min uden DB-aktivitet (DB-mtime som fremdriftssignal).</li> En ydre watchdog hvert 10. minut</strong> tjekker supervisoren, DB-fremdrift og webserver lokalt — og det hele på workeren over SSH — og genstarter automatisk.</li> Falske “klar”-dage</strong> — en max-dato-heuristik erklærede en dag færdig, mens 93 af dens 104 filer stadig manglede. Modtræk: indbakken er ground truth</strong> — en dag/uge er først klar, når hver</em> fil har en afgjort DB-række. Ground truth slår heuristik; max-dato-gættet løj to gange, indbakke-optællingen aldrig.</strong></li> Anonyme opkald</strong> — filer fra et hemmeligt nummer matchede ikke filnavnsmønsteret og blev usynlige for dag-gruppering. Parser udvidet, rækker repareret.</li> En dublet-bug</strong> — identisk lyd under nyt navn blev markeret done</code> uden transskription (én hash delt af 103 tomme ring-ud-filer) og forurenede dag-dumps. Nu arver dubletter tvillingens status og indhold.</li> Høstede baggrundsprocesser</strong> — nohup</code>-jobs blev høstet af miljøet og døde ubemærket i timevis. Modtræk: alt langkørende arbejde som harness-managede baggrundstasks, med watchdoggen som bagstopper.</li> </ol> Selvheling skal være lagdelt:</strong> proces-niveau (supervisor: crash / hæng / poison / orphan) og</em> system-niveau (watchdog: supervisor død? web nede? worker væk?).</p> Tallene (pr. skrivende stund)</h2> </th> </th></tr></thead> Korpus</td> ~33.000 mp3, ~570 audiotimer, 13 måneder</td></tr> Behandlet</td> ~6.100 filer (19%), fra begge ender</td></tr> Resuméer</td> 60 dags- + 7 ugeresuméer</td></tr> Lokal hastighed</td> dual-model ~0,2 RTF; ~430 filer/time</td></tr> Dag-agent-omkostning</td> ~50k–450k subagent-tokens/dag (gns. ~200k)</td></tr> Diarisering</td> 2-taler-prior + kontekst-reparation reddede de 79% af lange opkald, der kollapsede til én stemme</td></tr> </tbody></table> Hvordan det kan bruges i en kundeservicefunktion</h2> Den oprindelige use case er personlig opkalds-intelligens, men præcis den samme pipeline er et kundeservice</strong>-system:</p> To-spors-ASR + LLM-fusion</strong> → præcise danske transskriptioner af supportopkald.</li> Resuméer pr. opkald / dag / uge</strong> → QA uden at lytte til hvert opkald.</li> Løftetabellen</strong> generaliserer direkte til SLA-/løfte-tracking</strong> — hvad en agent lovede en kunde, og om det blev leveret, ført videre uge for uge.</li> Det fælles navneregister</strong> → et konsistent kunde-/kontaktkartotek bygget fra opkaldene selv.</li> Mønster-visningen</strong> (volumen pr. time, retningsasymmetri, tilbagevendende emner) → bemandings- og eskaleringsindsigt, alt sammen fra metadata + resuméer.</li> PII-disciplin</strong> er indbygget: “opfind aldrig, flag usikkerhed”-reglen og redigering før noget gemmes.</li> </ul> Og privatlivshistorien er salgsargumentet: alt kører lokalt bag Tailscale</strong> — lyden forlader aldrig bygningen, du sætter opbevaring og redigering, og der er intet offentligt endpoint. (Den ærlige grænse: hvis dit sproglag er et cloud-LLM-API frem for et lokalt harness, forlader den tekst stedet — så redigér først, eller hold LLM’en lokal også.)</p> Lektionerne, destilleret</h2> Analysér ligene først</strong> — ni døde eksperimenter rummede næsten alle de rigtige idéer. Syntese slår opfindelse.</li> Metadata er guld</strong> — filnavne alene gav taleridentitet, dagsstruktur og hele mønsteranalysen, før et sekund lyd var afkodet.</li> To middelmådige, forskellige ASR-spor + en model der fletter dem slår ét godt spor.</strong> Fejl-diversitet er pointen.</li> SOTA er opgaveafhængigt</strong> — neural denoise skadede</em> ASR målbart; et 50 år gammelt båndpas hjalp.</li> Idempotens er friheden til at fejle</strong> — hash + status gjorde hvert crash, genstart og midt-i-kørslen-migrering harmløst.</li> Selvheling i lag</strong> — supervisor for processen, watchdog for systemet.</li> Ground truth frem for heuristik</strong> til fremdriftsgates — tæl indbakken, gæt ikke fra max-datoen.</li> En LLM kan være pipelinens dyre trin uden et API</strong> — når harnesset selv er modellen, er et “resumé-trin” en subagent med en god instruksfil, et fælles register og en ærlighedsnorm.</li> </ol> Nulstil en Yealink-telefon til fabriksindstillinger — også uden admin-adgangskoden (2026) 2026-06-10T00:00:00+00:00 Kort fortalt —</strong> For at fabriksnulstille en Yealink</strong> SIP-bordtelefon har du tre muligheder: tastaturmenuen</strong> (kræver admin-adgangskoden), web-UI’en</strong> (kræver admin-adgangskoden) eller et hardware-tastetryk</strong>, der slet ikke kræver adgangskode</strong> — hold OK</strong>-tasten i ~10 sekunder. Den sidste er den, du vil bruge til en brugt eller arvet telefon med ukendt admin-login. Dette dækker også standardadgangskode-situationen i 2026: gammel firmware er admin</code>/admin</code>, nyere enheder leveres med en unik adgangskode på en label</strong>.</p> Standardadgangskoden, dengang → nu</h2> Det her snubler folk over, så få det på plads først:</p> Ældre firmware:</strong> brugernavn admin</code>, adgangskode admin</code>. Den klassiske standard.</li> Nyere firmware (sikkerhedshærdning, ~2021 og frem):</strong> Yealink leverer hver telefon med en unik tilfældig standardadgangskode</strong> trykt på et klistermærke (typisk på undersiden eller æsken), eller tvinger dig til at sætte en ny adgangskode ved første web-login. Så admin</code>/admin</code> virker ikke</strong> på nyere enheder.</li> </ul> Hvis du har adgangskoden, så nulstil fra menuen eller web-UI’en. Hvis du ikke har den, så spring til hardware-nulstillingen</strong> — den rydder adgangskoden helt.</p> Metode 1 — Hardware-nulstilling (ingen admin-adgangskode nødvendig)</h2> Det er den, de fleste søger efter. Med telefonen tændt og i hviletilstand</strong> (ikke i et opkald, ikke i en menu):</p> Tryk og hold OK-tasten</strong> — den runde/midterste tast under skærmen — i cirka 10 sekunder</strong>.</li> Skærmen viser “Nulstil til fabriksindstillinger?”</strong></li> Tryk OK</strong> for at bekræfte.</li> Telefonen sletter alt og genstarter. Det tager et minut eller to; afbryd den ikke.</li> </ol> Intet login nødvendigt — dette nulstiller admin-adgangskoden sammen med alt andet. (På enkelte modeller udløses prompten ved at holde X</strong>-/annuller-tasten i stedet; hvis OK ikke gør det, så prøv den.)</p> Metode 2 — Fra telefonens tastatur (kræver admin-adgangskode)</h2> Tryk på Menu</strong>-softtasten.</li> Gå til Indstillinger → Avancerede indstillinger</strong>, og indtast admin-adgangskoden (admin</code> på gammel firmware, eller label-adgangskoden).</li> Vælg Nulstil til fabriksindstillinger</strong> (nogle gange Reset Config</strong>), og bekræft.</li> </ol> Metode 3 — Fra webgrænsefladen (kræver admin-adgangskode)</h2> Find telefonens IP: Menu → Status</strong> (eller Indstillinger → Status</strong>).</li> Gå til http://<telefon-ip>/</code>, og log ind som admin</code>.</li> Gå til Settings → Upgrade</strong> (eller Reset & Reboot</strong>), og klik Reset to Factory</strong>.</li> </ol> Efter nulstillingen</h2> En fuld nulstilling sletter SIP-kontoen, netværkskonfigurationen, kontakter og opkaldshistorik</strong> — telefonen kommer tilbage som ny. Før du nulstiller (hvis du kan logge ind), så notér dine SIP-oplysninger</strong> (server/registrar, brugernavn, auth-ID, adgangskode), så du kan genregistrere den bagefter. På nyere firmware bliver du bedt om at sætte en frisk admin-adgangskode ved første login igen.</p> Opsummering</h2> Ingen admin-adgangskode?</strong> Hold OK</strong>-tasten ~10 s i hviletilstand → bekræft → færdig. Intet login nødvendigt.</li> Har adgangskoden?</strong> Nulstil fra Menu → Indstillinger → Avanceret</strong>, eller web-UI’en</strong> på http://<telefon-ip>/</code>.</li> Standardadgangskode:</strong> admin</code>/admin</code> på gammel firmware; en unik label-adgangskode</strong> på nyere enheder.</li> En fabriksnulstilling sletter SIP-kontoen og kontakter</strong> — gem dine SIP-oplysninger først.</li> </ul> Opdater Garmin-firmware og -kort i 2026 — fra WebUpdater til Garmin Express 2026-06-10T00:00:00+00:00 Kort fortalt —</strong> Hvis du søgte efter Garmin WebUpdater</em> eller hvordan opdaterer jeg Garmin-firmware</em>, er værktøjet, du husker, væk. WebUpdater blev nedlagt (~2015)</strong>; den nuværende vej er Garmin Express</strong> (et skrivebordsprogram, USB-kabel) til nüvi/DriveSmart-navigatorer, eller Garmin Connect</strong> (telefon, trådløst) til ure og nyere håndholdte. Dette indlæg dækker 2026-måden at opdatere firmware og kort</strong> på hver, hvad du gør med en gammel nüvi, og den skjulte nüvi-debugmenu</strong>.</p> Dengang → nu: WebUpdater er død</h2> I årevis opdaterede du en Garmin med WebUpdater</strong> — en lille skrivebordshjælper, der tjekkede for firmware. Garmin pensionerede den og samlede alt i to apps:</p> Garmin Express</strong> — skrivebord (Windows/macOS), forbinder via USB-kabel</strong>. Det er det, der erstattede WebUpdater til navigatorer (nüvi, DriveSmart, Drive) og er også kabelvejen til ure/håndholdte og kort</strong>opdateringer.</li> Garmin Connect</strong> — telefon-app (iOS/Android), opdaterer trådløst</strong> over Bluetooth/Wi-Fi. Det er vejen til ure (Forerunner, fēnix, Venu), cykelcomputere (Edge) og moderne håndholdte.</li> </ul> Hvis du stadig har WebUpdater installeret, så afinstallér det — det gør ikke længere noget nyttigt.</p> Opdater en nüvi / DriveSmart-navigator (firmware + kort)</h2> Det er tilfældet bag de fleste “opdater Garmin-firmware”-søgninger.</p> Hent Garmin Express</strong> fra garmin.com/express</a> og installér det på en Windows- eller Mac-computer.</li> Tilslut enheden med et USB-kabel</strong> og tænd den. Vent på, at computeren genkender den som et drev.</li> Åbn Garmin Express. Den finder enheden og viser tilgængelige software- (firmware)</strong> og kort</strong>opdateringer.</li> Klik Installér alle</strong>, eller vælg enkelte opdateringer. Kortfiler er store (ofte flere GB) — lad den være tilsluttet, og afbryd ikke midt i.</li> Når den er færdig, så skub sikkert ud og frakobl. Enheden genstarter med den nye firmware.</li> </ol> Kortopdateringer</strong> vises også her. Hvis din enhed har lifetime maps</strong> (“LM”/“LMT” i modelnavnet), er opdateringer gratis i enhedens understøttede levetid. Ellers tilbyder Express et betalt kortkøb.</p> Opdater et ur / Edge / nyere håndholdt (trådløst)</h2> Installér Garmin Connect</strong> på din telefon, og parr enheden.</li> Connect henter opdateringer automatisk; du får en besked, når firmware er klar.</li> Hold enheden opladt og nær telefonen — den installerer og genstarter af sig selv.</li> </ol> For en kabelopdatering af disse enheder (eller hvis trådløst fejler) virker Garmin Express på en computer også.</p> Meget gamle nüvi-enheder — hvad der stadig virker</h2> Mange tidlige nüvi-modeller (2007–2012-æraen) er nu udgået</strong>: firmware kan måske stadig installeres via Garmin Express, men kortopdateringer tilbydes ikke længere</strong>, og lifetime-maps-dækningen er ophørt. Hvis Express viser “opdateret” med et gammelt kortår, er det som regel vejs ende — hardwaren understøttes simpelthen ikke med nye kortdata mere. Enheden virker fortsat med de kort, den har.</p> Bonus: den skjulte nüvi-debugmenu</h2> Et gammelt trick til at diagnosticere en ustabil nüvi: tænd den, og tryk og hold nederste højre hjørne af berøringsskærmen</strong> i nogle sekunder. En diagnoseskærm</strong> dukker op — softwareversion, kalibreringstest af berøringsskærm, GPS-signaltest, batteriinfo. Det er sikkert at se på; undgå at ændre berøringsskærmskalibrering, medmindre skærmen reelt er skæv.</p> Opsummering</h2> WebUpdater er nedlagt</strong> — brug Garmin Express</strong> (skrivebord, USB) eller Garmin Connect</strong> (telefon, trådløst).</li> nüvi / DriveSmart</strong>: Garmin Express over USB klarer både firmware og kort; “Installér alle”.</li> Ure / Edge / håndholdte</strong>: Garmin Connect opdaterer trådløst.</li> Lifetime maps</strong> (LM/LMT-modeller) opdaterer gratis; meget gamle nüvi-enheder er udgået for nye kortdata.</li> nüvi-debugmenu</strong>: hold nederste højre hjørne af skærmen efter opstart.</li> </ul> Whisper-backend-dyst: faster-whisper vs HF Transformers vs whisper.cpp (2026) 2026-06-10T00:00:00+00:00 Kort fortalt —</strong> På et RTX 4070 Ti med telefoni-optimeret lydforbehandling når faster-whisper</code> med large-v3-turbo</code> ~56× realtid</strong> — hurtigst samlet. whisper.cpp</code> CUDA er tæt på (~40×)</strong> ved en brøkdel af VRAM’en. Batched HF Transformers</strong> (SDPA, batch 24) er konkurrencedygtig på turbo-modellen. På CPU matcher whisper.cpp</code> overraskende GPU-hastigheder for korte filer; faster-whisper</code> int8 er stadig praktisk ved ~5×.</p> En del af det danske voicelog-projekt</a> — dette er backend-benchmarken bag pipelinens ASR-valg. Se også at køre Whisper lokalt</a>.</p> </blockquote> Opsætning</h2> </th> </th></tr></thead> GPU</strong></td> NVIDIA GeForce RTX 4070 Ti (12 GB VRAM)</td></tr> CPU</strong></td> Intel Core i5-13400F (16 tråde)</td></tr> RAM</strong></td> 125 GB</td></tr> CUDA</strong></td> 12.9 / Driver 595</td></tr> faster-whisper</strong></td> 1.2.1 (CTranslate2 4.8.0)</td></tr> transformers</strong></td> 5.10.2</td></tr> whisper.cpp</strong></td> kompileret fra kilde, CUDA aktiveret</td></tr> PyTorch</strong></td> 2.12.0</td></tr> </tbody></table> Lyd-testsæt</h2> Tre rigtige danske telefonopkald fra et dansk voicelog-korpus (filnavne anonymiseret til Fil 1–3</code>):</p> Fil</th> Varighed</th> Noter</th></tr></thead> Fil 1</strong></td> 1m 26s</td> Autentisk dansk samtaletale</td></tr> Fil 2</strong></td> 13m 26s</td> Autentisk dansk samtaletale</td></tr> Fil 3</strong></td> 1m 51s</td> Autentisk dansk samtaletale</td></tr> </tbody></table> Der findes ingen referencetransskriptioner — kvalitet vurderes via konsensus-WER</strong> (parvis enighed på tværs af modeller) og relativ WER</strong> (afstand til konsensus-vinderen).</p> </blockquote> Backends i test</h2> Backend</th> Engine</th> Nøgleteknik</th> Modeller</th></tr></thead> faster-whisper</strong></td> CTranslate2</td> int8/float16-kvantiserede kerner</td> large-v3, large-v3-turbo</td></tr> HF Transformers (batched)</strong></td> PyTorch (SDPA)</td> batch_size=24, flash-attention via SDPA</td> large-v3, large-v3-turbo</td></tr> whisper.cpp</strong></td> ggml</td> CUDA-kerne-offload / AVX CPU</td> large-v3, large-v3-turbo</td></tr> </tbody></table> Resultater: hastighed (RTF — lavere er bedre)</h2> RTF = transskriptionstid ÷ lydvarighed. RTF 0,03 = 33× realtid.</em></p> Backend / Model / Enhed</th> Fil 1</th> Fil 2</th> Fil 3</th> Gns. RTF</strong></th> Fart</strong></th></tr></thead> faster-whisper / large-v3-turbo / CUDA</td> 0.021</td> 0.013</td> 0.019</td> 0.018</strong></td> 56×</strong></td></tr> faster-whisper / large-v3 / CUDA</td> 0.047</td> 0.033</td> 0.051</td> 0.043</strong></td> 23×</strong></td></tr> HF Transformers (b24, SDPA) / large-v3-turbo / CUDA</td> 0.040</td> 0.062</td> 0.036</td> 0.046</strong></td> 22×</strong></td></tr> HF Transformers (b2, SDPA) / large-v3 / CUDA</td> 0.180</td> 0.142</td> 0.222</td> 0.181</strong></td> 6×</strong></td></tr> whisper.cpp / large-v3-turbo / CUDA</td> 0.028</td> 0.017</td> 0.030</td> 0.025</strong></td> 40×</strong></td></tr> whisper.cpp / large-v3 / CUDA</td> 0.070</td> 0.050</td> 0.080</td> 0.067</strong></td> 15×</strong></td></tr> faster-whisper / large-v3-turbo / CPU</td> 0.208</td> 0.151</td> 0.248</td> 0.203</strong></td> 5×</strong></td></tr> faster-whisper / large-v3 / CPU</td> 0.470</td> 0.354</td> 0.714</td> 0.513</strong></td> 2×</strong></td></tr> whisper.cpp / large-v3-turbo / CPU</td> 0.034</td> 0.017</td> 0.027</td> 0.026</strong></td> 39×</strong></td></tr> whisper.cpp / large-v3 / CPU</td> 0.071</td> 0.050</td> 0.084</td> 0.068</strong></td> 15×</strong></td></tr> </tbody></table> Resultater: VRAM-forbrug (GPU-kørsler)</h2> Backend / Model</th> Gns. VRAM (MB)</th></tr></thead> HF Transformers (b24, SDPA) / large-v3-turbo / CUDA</td> 3884</td></tr> HF Transformers (b2, SDPA) / large-v3 / CUDA</td> 5727</td></tr> </tbody></table> Resultater: kvalitet (konsensus-WER)</h2> Konsensus-WER måler, hvor meget hver models output afviger fra gruppegennemsnittet. Lavere = mere lig det, alle modeller er enige om.</p> Backend / Model / Enhed</th> Fil 1</th> Fil 2</th> Fil 3</th> Gns. relativ WER</th></tr></thead> faster-whisper / large-v3-turbo / CUDA</td> 0.132</td> 0.359</td> 0.226</td> 0.239</strong></td></tr> faster-whisper / large-v3 / CUDA</td> 0.230</td> 0.334</td> 0.294</td> 0.286</strong></td></tr> HF Transformers (b24, SDPA) / large-v3-turbo / CUDA</td> 0.237</td> 0.601</td> 0.229</td> 0.356</strong></td></tr> HF Transformers (b2, SDPA) / large-v3 / CUDA</td> 0.152</td> 0.225</td> 0.326</td> 0.234</strong></td></tr> whisper.cpp / large-v3-turbo / CUDA</td> 0.000</td> 0.673</td> 0.000</td> 0.224</strong></td></tr> whisper.cpp / large-v3 / CUDA</td> 0.187</td> 0.000</td> 0.553</td> 0.247</strong></td></tr> faster-whisper / large-v3-turbo / CPU</td> 0.136</td> 0.344</td> 0.191</td> 0.224</strong></td></tr> faster-whisper / large-v3 / CPU</td> 0.249</td> 0.339</td> 0.274</td> 0.287</strong></td></tr> whisper.cpp / large-v3-turbo / CPU</td> 0.000</td> 0.673</td> 0.000</td> 0.224</strong></td></tr> whisper.cpp / large-v3 / CPU</td> 0.187</td> 0.000</td> 0.553</td> 0.247</strong></td></tr> </tbody></table> Kvalitetsvinder:</strong> faster-whisper / large-v3-turbo / CPU</code></p> </blockquote> Side om side: hvor backendsne adskilte sig</h2> Test-lyden er et privat opkald, så i stedet for at gengive det er her en neutral dansk sætning, der står som stedfortræder for den slags samtaletale, der blev testet — plus de afvigelsesmønstre, der faktisk dukkede op på tværs af backends på 86-sekunders-filen:</p> “Lad os tage mødet på torsdag, så gennemgår vi tallene sammen.”</em> (illustrativ)</p> </blockquote> Tabte indledninger.</strong> faster-whisper</code> large-v3 (CUDA og CPU) startede nogle gange et par ord inde og udelod en indledende sætning, som turbo-modellerne og whisper.cpp</code> fangede.</li> Uenighed om egennavne.</strong> Det indledende navn blev transskriberet på to forskellige måder på tværs af backends — det klassiske problem med navne i et sprog med få ressourcer, hvor hver model gætter en anden plausibel stavemåde.</li> Forvanskede navneord på støjende segmenter.</strong> whisper.cpp</code> large-v3 lavede et klart navneord om til en næsten-homofon, som turbo-modellerne fik rigtigt.</li> Sjældne hallucinerede fragmenter.</strong> faster-whisper</code> large-v3 udsendte lejlighedsvis en kort nonsens-frase på en støjende strækning, hvor de andre backends holdt sig rene.</li> Mindre stavefejl.</strong> Turbo-CPU-kørslen producerede en og anden vokal-tastefejl, der ikke sås på GPU.</li> </ul> Netto: turbo-modellerne var mest konsekvent kohærente</strong>; fuld large-v3 var stærk, men mere tilbøjelig til tabte indledninger og en og anden hallucination på denne støjende telefonlyd.</p> Nøglefund</h2> Hurtigste GPU:</strong> faster-whisper / large-v3-turbo / CUDA</code> ved gns. RTF 0,018 (56× realtid).</li> Turbo-speedup (faster-whisper GPU):</strong> large-v3-turbo er 2,4× hurtigere end large-v3.</li> Hurtigste CPU:</strong> whisper.cpp / large-v3-turbo / CPU</code> ved gns. RTF 0,026.</li> GPU vs. CPU (faster-whisper turbo):</strong> GPU er 11,4× hurtigere end CPU int8.</li> Lavest VRAM:</strong> HF Transformers (b24, SDPA) / large-v3-turbo / CUDA</code> ved 3884 MB.</li> </ul> Anbefalinger</h2> Use case</th> Anbefaling</th></tr></thead> Produktions-pipeline (GPU-server)</strong></td> faster-whisper</code> + large-v3-turbo</code> + float16</code> — bedste hastighed/kvalitet/VRAM</td></tr> Højeste præcision (GPU, ingen hastighedsbinding)</strong></td> faster-whisper</code> + large-v3</code> + float16</code></td></tr> Batched offline-behandling</strong></td> HF Transformers batched (SDPA) + large-v3-turbo</code>, batch_size=24</td></tr> Embedded / ingen Python-runtime</strong></td> whisper.cpp</code> CUDA — én binær, lavt overhead</td></tr> CPU-only-server</strong></td> faster-whisper</code> + large-v3-turbo</code> + int8</code></td></tr> Edge / Raspberry Pi</strong></td> whisper.cpp</code> CPU + large-v3-turbo</code> (mindste RAM-fodaftryk)</td></tr> </tbody></table> Metodenoter</h2> Hver backend/model/enhed-kombination kører som en separat proces</strong> for at garantere fuld GPU-hukommelses-frigivelse mellem kørsler.</li> faster-whisper GPU bruger compute_type=float16</code>; CPU bruger int8</code>.</li> HF Transformers bruger attn_implementation=sdpa</code> (PyTorch SDPA / FlashAttention-ækvivalent, ingen ekstra installation).</li> whisper.cpp bruger CUDA automatisk, når den er kompileret med GGML_CUDA=ON</code> — intet flag nødvendigt; CPU-kørsler bruger -t 8</code> (systemets trådantal).</li> Al lyd forbehandles med ffmpeg før transskribering: highpass=f=200,lowpass=f=3400,afftdn=nr=10:nf=-25,dynaudnorm</code> (telefon-båndpas + let denoise + loudness-normalisering).</li> VRAM måles via torch.cuda.max_memory_allocated()</code>; ikke tilgængeligt for whisper.cpp-subprocess-kørsler.</li> Al lyd er dansk samtale-telefontale — resultater kan variere på andre sprog eller lydforhold.</li> Konsensus-WER beregnes parvist på tværs af alle modeller; modellen med lavest gennemsnitlig parvis WER er “konsensus-vinderen”.</li> </ul> Fra Launchy til Raycast: tastaturstarterens historie (2007 → 2026) 2026-06-07T00:00:00+00:00 TL;DR —</strong> I 2007 lagde jeg en kort screencast op af Launchy</a></strong> — en “tastaturstyret applikationsstarter”, der lod dig fremkalde ethvert program på Windows ved at trykke en genvejstast og skrive nogle få bogstaver, i stedet for at lede i Start-menuen. Det mønster — genvejstast → skriv → fuzzy-match → start</strong> — blev født på Mac’en (Quicksilver, LaunchBar), kom til Windows med Launchy, spredte sig til Linux og gjorde så to ting på én gang: den modnedes til fulde produktivitetsplatforme (Alfred</strong>, så Raycast</strong>), og den opløste sig i Cmd+K-kommandopaletten</strong>, der nu bor inde i næsten alle apps, du bruger. Her er buen over 19 år.</p> En pendant til de andre tidskapsel-indlæg her — som Xming på Windows XP → WSLg</a> og 25 års Wi-Fi-sikkerhed</a>. En gammel screencast, og hvad idéen voksede til.</p> </blockquote> Opsætningen, dengang</h2> Videoen</a> (“Shiny Windows Application Launcher” — Shiny</em> var et Launchy-skin) viser arbejdsgangen fra 2007. Du installerer Launchy</strong>, den indekserer din Start-menu, og fra da af:</p> Tryk Alt+Space</strong>. En lille gennemsigtig boks dukker op midt på skærmen.</li> Skriv nogle få bogstaver — fir</code> for Firefox, wor</code> for Word.</li> Launchy fuzzy-matcher mod alt, den har indekseret, og viser det bedste hit.</li> Tryk Enter</strong>. Appen starter. Boksen forsvinder.</li> </ol> Ingen mus, ingen Start-menu, ingen skrivebordsikoner. Efter en uge kendte dine fingre tre-bogstavs-præfikset for hver app, du brugte. Launchy — skrevet af Josh Karlin og open-sourcet — blev udtrykkeligt markedsført som “Quicksilver til Windows”</strong>, og den sammenligning er nøglen til hele historien.</p> Hvor idéen faktisk kom fra</h2> Launchy opfandt ikke tastaturstarteren — den bragte en Mac</strong>-idé til Windows:</p> LaunchBar</strong> (Objective Development) — bedstefaderen, med rødder på NeXTSTEP i 1990’erne</strong>, genfødt på Mac OS X. Skriv en forkortelse, få tingen.</li> Quicksilver</strong> (Nicholas Jitkoff / Blacktree, ~2003) — den legendariske, nærmest mystiske Mac-starter. Ikke bare “start en app”, men en verbum-navneord-grammatik: vælg en ting</em>, vælg en handling</em>, vælg et mål</em>. Den definerede genren og inspirerede en hel generation (den blev open-sourcet i 2007, da skaberen tog til Google).</li> Spotlight</strong> (Mac OS X Tiger, 2005) — Apple bagte søgning ind i styresystemet, hvilket er der, de fleste almindelige brugere mødte “skriv bare for at finde ting”-idéen.</li> </ul> Launchy (2004→) var Windows-svaret på alt det, og videoen fra 2007 er et øjebliksbillede af den på toppen.</p> Et hurtigt overblik — 19 år med startere</h2> Æra</th> macOS</th> Windows</th> Linux</th> Mønsteret</th></tr></thead> ~2003–05</strong></td> Quicksilver, LaunchBar, Spotlight</td> Start-menu (Vista får søgning, 2007)</td> —</td> Starteren er en Mac-power-user-ting</td></tr> 2007 (videoen)</strong></td> Quicksilver på toppen</td> Launchy</strong> (“Quicksilver til Windows”)</td> —</td> Tastaturstarteren krydser til Windows</td></tr> ~2008–10</strong></td> Quicksilver stagnerer → Alfred</strong> (2010)</td> Launchy topper, så sløver</td> GNOME Do</strong>, Katapult</td> Starteren bliver mainstream-power-user</td></tr> ~2011–15</strong></td> Alfred + Powerpack dominerer</td> Wox (2014)</td> Synapse, Albert</td> Kommandopaletten</strong> dukker op (Sublime, så VS Code)</td></tr> ~2016–20</strong></td> Raycast</strong> grundlægges (2020)</td> PowerToys Run</strong> (2020), Flow Launcher</td> Rofi, Ulauncher</td> Cmd+K spreder sig til hver web-app</td></tr> 2026 (i dag)</strong></td> Raycast dominerer; Spotlight + Apple Intelligence</td> PowerToys Command Palette</strong>; Raycast (beta)</td> Rofi / Ulauncher / Albert</td> Starteren = AI-drevet kommando-hub</td></tr> </tbody></table> Hvad der ændrede sig</h2> 1. Starteren blev en platform.</strong> Launchy startede apps og filer. Alfred</strong> (2010) tilføjede workflows</em> — kæd handlinger sammen, kør scripts, udklipshistorik, snippets — og blev Mac-standarden i et årti. Så genopbyggede Raycast</strong> (2020) idéen som en native, udvidelig platform: en udvidelsesbutik, vinduesstyring, udklipshistorik, snippets, lommeregnere og nu indbygget AI</strong>. Den ydmyge start-boks blev til stedet, hvor power-brugere kører halvdelen af deres dag. Raycasts Windows-beta kom sidst i 2025</strong> og lukkede ringen tilbage til der, hvor Launchy startede.</p> 2. Windows blev ved med at genopfinde den.</strong> Launchy ebbede ud efter ~2010. Wox</strong> (open source, 2014) bar faklen videre og affødte Flow Launcher</strong> (en Wox-fork med en plugin-markedsplads og AI-plugins). Microsoft selv udgav PowerToys Run</strong> (2020, Alt+Space</code> — et vidende nik til Launchy), nu afløst af PowerToys Command Palette</strong>. Mønsteret er så åbenlyst godt, at OS-producenten adopterede det.</p> 3. Linux havde altid sin egen.</strong> GNOME Do</strong> (2008) var den tidlige Quicksilver-lignende; i dag er det Rofi</strong> og dmenu</strong> (minimale, scriptbare, elskede af tiling-WM-brugere), Ulauncher</strong> og Albert</strong>. Samme muskelhukommelse, andet økosystem.</p> 4. Det største skift: starteren opløste sig i hver app.</strong> Det definerende træk i det seneste årti er ikke en bedre starter — det er, at kommandopaletten</em> blev en universel UX-primitiv. Sublime Text</strong> (~2011) og så VS Code</strong> (Ctrl/Cmd+Shift+P</code>) gjorde “tryk en genvejstast, skriv en kommando” til måden, man styrer en editor på. Så dukkede Cmd+K</strong> op overalt: Slack, Linear, Notion, GitHub, Figma, Vercel, Stripe, din browser. Tastaturstarteren holdt op med at være en separat app, du installerer, og blev en kontrol indbygget i selve softwaren. I terminalen er fzf</strong> (2013) den samme idé destilleret til én fuzzy-finder-binær.</p> 5. Så åd AI’en kommandobaren.</strong> Den nyeste drejning: boksen, du skriver i, taler nu med en model. Raycast AI</strong>, Flow Launchers AI-plugins, Spotlight + Apple Intelligence</strong>, Windows Copilot</strong>. “Genvejstast → skriv → fuzzy-match → handl” bliver til “genvejstast → spørg → starteren regner handlingen ud”. Launchys lille gennemsigtige boks var larvestadiet for nutidens AI-kommandobar.</p> Hvad du skal bruge i dag</h2> macOS</strong> — Raycast</a></strong> er den moderne standard: start, udklipshistorik, vinduesstyring, snippets, en udvidelsesbutik og AI i én genvejstast. Alfred</a></strong> er alternativet, hvis du foretrækker et engangskøb og lokal automatisering. Spotlight er indbygget og efterhånden ret god.</p> Windows</strong> — PowerToys Command Palette</strong> (officiel, gratis, følger med PowerToys</a>), Flow Launcher</a></strong> (open source, plugin-markedsplads) eller Raycast</strong> (Windows-beta siden sidst i 2025). Par hvilken som helst af dem med Everything</a></strong> til lynhurtig filsøgning.</p> Linux</strong> — Rofi</strong> eller dmenu</strong> til den scriptbare/tiling-flok, Ulauncher</strong> eller Albert</strong> til en venligere GUI.</p> Terminal</strong> — fzf</a></strong>. Pipe hvad som helst ind i den, fuzzy-find, handl. Starter-idéen i 30 linjers muskelhukommelse.</p> Pointen</h2> Launchy-klippet fra 2007 ser gammeldags ud — en gennemsigtig boks, et Shiny-skin, tre bogstaver og Enter. Men idéen i det vandt fuldstændigt. Den begyndte som en Mac-kuriositet, Launchy bragte den til Windows, Linux samlede den op, og derfra gik den i to retninger på én gang: opad</em> til produktivitetsplatforme som Raycast, og sidelæns</em> ind i hver app som Cmd+K-kommandopaletten. I dag bruger du den idé fra 2007 snesevis af gange om dagen — du installerer den bare ikke længere, for den er overalt. Og boksen er begyndt at tænke.</p> FAQ</h2> Hvad var Launchy?</h3> En gratis, open source tastaturstarter til Windows (senere på tværs af platforme), først udgivet af Josh Karlin omkring 2004. Genvejstast, skriv nogle få bogstaver, fuzzy-match, start — “Quicksilver til Windows”. Videoen fra 2007 viser den på Shiny-skinnet.</p> Vedligeholdes Launchy stadig?</h3> Nej — udviklingen ebbede ud omkring 2010, og den er reelt gået i dvale. På Windows i dag: brug PowerToys Command Palette, Flow Launcher eller Raycast.</p> App-starter vs. kommandopalette — hvad er forskellen?</h3> Samme mønster, anden afgrænsning. En starter (Quicksilver, Launchy, Alfred, Raycast) er systemdækkende; en kommandopalette (VS Codes Ctrl+Shift+P</code>, Cmd+K</code>-baren i Slack/Linear/GitHub) er den samme UX inde i én app. Starteren kom først; paletten er den absorberet ind i alting.</p> Hvad skal jeg bruge i 2026?</h3> macOS: Raycast eller Alfred. Windows: PowerToys Command Palette, Flow Launcher eller Raycast. Linux: Rofi, Ulauncher eller Albert. Terminal: fzf.</p> Opsummering</h2> Tastaturstarteren — genvejstast → skriv → fuzzy-match → start</strong> — begyndte på Mac’en (LaunchBar</strong>, Quicksilver</strong>) og nåede Windows via Launchy</strong>, som min video fra 2007</a> demonstrerer.</li> Den voksede opad</em> til platforme: Alfred</strong> (2010) → Raycast</strong> (2020), nu AI-drevet, med en Windows-beta</strong> fra sidst i 2025.</li> Windows blev ved med at genopfinde den: Wox</strong> → Flow Launcher</strong>, og Microsofts PowerToys Run → Command Palette</strong>.</li> Den spredte sig også sidelæns</em> ind i hver app som Cmd+K-kommandopaletten</strong> (Sublime/VS Code → Slack, Linear, Notion, GitHub) og ind i terminalen som fzf</strong>.</li> Idéen fra 2007 er nu overalt — og i stigende grad en AI-kommandobar.</li> </ul> Fra Xming på Windows XP til WSLg: 18 år med Linux-GUI-apps på Windows (2026) 2026-06-07T00:00:00+00:00 TL;DR —</strong> At køre en Linux-GUI-app på en Windows-maskine plejede at betyde, at man installerede en X-server</strong> (Xming, senere VcXsrv), pegede en SSH-session på den med ssh -X</code> og så et fjernt gedit</code>-vindue tegne sig selv op på Windows-skrivebordet. Jeg har en gammel skærmoptagelse af præcis det</a> — Xming, der sætter gedit på Windows XP</strong>. Atten år senere gider man stort set ikke: WSLg</strong> leverer en Wayland- + X-server inde i</em> Windows, så en Linux-app installeret i WSL2 bare åbner som ethvert andet vindue. Dette indlæg trækker buen op — X11-forwarding → VcXsrv → Wayland → WSLg — og hvad du faktisk skal bruge i 2026.</p> Det her er en pendant til de andre “dengang vs. nu”-noter på bloggen — som lokal tale-til-tekst, der afløser cloud-Speech-API’en</a> og 25 års Wi-Fi-sikkerhed</a>. Samme form: noget, der var fummelt i XP-æraen, er nu indbygget.</p> </blockquote> Opsætningen, dengang</h2> Videoen</a> viser det kanoniske trick fra midten af 00’erne. Delene:</p> Xming</strong> — en gratis X11-server til Windows (en port af X.Org-serveren). Den kørte i Windows’ systembakke og leverede et display</em>, som X-klienter kunne tegne til.</li> En SSH-klient</strong> — som regel PuTTY med “Enable X11 forwarding” sat til, eller ssh -X</code> fra Cygwin.</li> En fjern Linux-maskine</strong>, der kørte selve appen (gedit</code>, en editor) uden noget lokalt vindue af sin egen.</li> </ul> Flowet: SSH forbinder til Linux-værten, værten sætter $DISPLAY</code> til at tunnelere X11 tilbage gennem den krypterede SSH-kanal, appen tegner til Xming, og et Linux-vindue dukker op på Windows XP. Applikationen kører udelukkende på fjern-maskinen; kun pixels og input-events</em> rejser. Det virkede, fordi X11 var netværkstransparent fra dag ét</strong> — en designbeslutning fra 1984, der modnede til en reelt nyttig egenskab.</p> Det var smart, og det var også langsomt og skrøbeligt: hver menu og genoptegning var en round-trip, så over andet end et LAN føltes det som at vade gennem sirup.</p> Et hurtigt overblik — 18 år med Linux-GUI på Windows</h2> Æra</th> Sådan gjorde du</th> Hvad drev displayet</th> Smertepunkter</th></tr></thead> ~2007 (XP)</strong></td> ssh -X</code> / PuTTY → Xming</td> Xming X-server i bakken</td> Manuel install, snakkesalig X11, laggy over WAN</td></tr> ~2012</strong></td> Samme, eller X over VNC</td> Xming / Xming-mesa, VcXsrv kommer (2011)</td> X-server stadig en separat bevægelig del</td></tr> ~2017</strong></td> VcXsrv + WSL1</td> VcXsrv, sæt DISPLAY=localhost:0</code></td> WSL1-finurligheder, font-/clipboard-fejl</td></tr> ~2021</strong></td> WSL2 + manuel X-server, eller</em> WSLg-preview</td> VcXsrv / X410, så WSLg</td> Overgang; manuel DISPLAY</code>-eksport stadig normal</td></tr> 2026 (i dag)</strong></td> WSLg, indbygget</td> Weston (Wayland) + XWayland, automatisk</td> Stort set ingen — apt install</code>, appen åbner</td></tr> </tbody></table> Hvad der faktisk ændrede sig</h2> 1. X-serveren holdt op med at være din at administrere.</strong> I ~25 år var X-serveren noget, du</em> installerede og passede på Windows. Med WSLg</a> — annonceret ved Microsoft Build 2021, nu standard på Windows 11 og Windows 10 21H2+ — bundter Microsoft en hel display-stak ind i en system-distro: en Weston</strong> Wayland-compositor, XWayland</strong> til gamle X11-apps, en PulseAudio-server til lyd og et RDP-link, der tegner vinduerne op på Windows-skrivebordet. Du installerer en Linux-GUI-app i WSL2, og den åbner. Ingen DISPLAY</code>, intet bakke-ikon, ingen PuTTY-afkrydsning.</p> # Inde i WSL2 på Windows 11 — ingen X-server at installere: sudo apt update && sudo apt install -y gedit gedit # et rigtigt Linux-gedit-vindue åbner på Windows </code></pre> 2. Wayland afløste X11 på Linux-siden.</strong> Protokollen, der gjorde det oprindelige trick muligt, er på vej ud. Moderne Linux-skriveborde defaulter til Wayland</strong>, som — i modsætning til X11 — ikke</em> er netværkstransparent. Så “bare forward det over SSH”-reflekset passer ikke længere rent; det Wayland-native svar på fjern-visning er waypipe</code></a>, og XWayland holder gamle X11-apps kørende i mellemtiden.</p> 3. Xming selv visnede til en betalt niche.</strong> Xming lever stadig — Colin Harrison udgav 7.7.x-builds så sent som januar 2026 — men den frit tilgængelige offentlige udgave frøs ved 6.9.0.31 i 2007</strong>; nyere versioner er donations-låst. Den gratis, aktivt vedligeholdte fakkel gik videre til VcXsrv</a></strong>, en open source-X-server bygget fra nuværende X.Org-kilder. (Bemærk: VcXsrv droppede Windows XP-understøttelse for længst — den æra er reelt forbi.)</p> 4. Selve grunden</em> fordampede stort set.</strong> I 2007 forwardede man en editor, fordi det var smertefuldt at redigere fjern-filer på nogen anden måde. I 2026 ville du gribe efter VS Codes Remote-SSH</strong>, montere fjern-filsystemet med sshfs</a> eller bare arbejde i en terminal over nøglebaseret SSH</a>. At forwarde et enkelt GUI-vindue er nu undtagelsen, ikke arbejdsgangen.</p> Hvad du skal bruge i dag</h2> Du er på WSL2 (Windows 11 / Win10 21H2+):</strong> gør ingenting. WSLg er der allerede. apt install</code> appen og kør den. Tjek med:</p> echo $WAYLAND_DISPLAY # wayland-0 → WSLg er aktiv echo $DISPLAY # :0 → XWayland til gamle X11-apps </code></pre> Du skal forwarde en GUI-app fra en fjern Linux-server til Windows:</strong> installér VcXsrv</strong>, start den (multiple-windows-tilstand, slå adgangskontrol fra — kun på et betroet netværk), og:</p> ssh -X user@server # -Y til betroet forwarding, hvis -X er blokeret xterm # eller hvilken GUI-app som helst — den tegner til VcXsrv </code></pre> Det er præcis</em> den samme mekanisme som i Xming-klippet, bare med en moderne X-server. Det virker stadig. Det er stadig snakkesaligt over latency.</p> Du vil have fjern-GUI, der ikke kravler over WAN:</strong> drop rå X11. Brug xpra</code></a> (“screen for X” — apps overlever afbrydelser, og det komprimerer godt), waypipe</code> til Wayland eller en rigtig remote-desktop-protokol (RDP via xrdp</code>, eller NoMachine/NX) til et fuldt skrivebord.</p> Pointen</h2> XP-klippet er en lille tidskapsel: en bakke-ikon-X-server, en PuTTY-tunnel og en Linux-teksteditor, der materialiserer sig på et beige XP-skrivebord. Idéen</em> — kør appen derovre, se den herovre — forsvandt aldrig. Det, der ændrede sig, er, at du ikke længere samler det i hånden. X-serveren flyttede ind i Windows, X11 gav plads til Wayland, og det almindelige tilfælde (“jeg vil bare røre filer på den maskine”) fik bedre svar helt af sig selv. Atten års VVS, stille og roligt absorberet ind i apt install</code>.</p> FAQ</h2> Virker SSH X11-forwarding stadig i 2026?</h3> Ja — ssh -X</code> (eller -Y</code> til betroet forwarding) er uændret. Det forwarder X11 til en hvilken som helst X-server: VcXsrv, Xming, XQuartz eller WSLg’s. Det er bare snakkesaligt over latency, hvilket er grunden til, at xpra/waypipe/RDP som regel vinder til fjern-arbejde i dag.</p> Vedligeholdes Xming stadig?</h3> Builds dukker stadig op (7.7.x i 2026), men de er donations-låst; den sidste gratis offentlige udgave var 6.9.0.31 i 2007 — Windows XP-æraen for klippet. Vil du have en gratis, aktivt bygget X-server til Windows, så brug VcXsrv.</p> Skal jeg overhovedet bruge en X-server?</h3> Kun til at forwarde GUI-apps fra en fjern maskine over SSH, eller til at køre X-apps fra en ikke-WSLg-distro. På WSL2 med Windows 11 (eller Win10 21H2+) leverer WSLg allerede en — lokale Linux-GUI-apps åbner uden noget ekstra installeret.</p> Hvorfor brød Wayland det gamle “forward det over SSH”-trick?</h3> X11 var netværkstransparent af design, så forwarding var gratis. Wayland er det bevidst ikke — fjern-visning er et separat anliggende, der håndteres af waypipe eller RDP. WSLg dækker over det ved at køre Weston + XWayland, så begge slags app virker.</p> Opsummering</h2> Den gamle måde: installér Xming</strong>, sæt X11-forwarding til i PuTTY, ssh -X</code>, og en fjern Linux-app tegner op på Windows. Videoen</a> er det, på Windows XP.</li> I dag: WSLg</strong> leverer en Wayland- + X-server inde i Windows — apt install</code> en Linux-app i WSL2, og den åbner bare.</li> VcXsrv</strong> er den gratis, vedligeholdte afløser for Xming til det klassiske fjern-forwarding-tilfælde; Xming</strong> selv blev donations-kun efter 6.9.0.31 (2007).</li> Wayland</strong> afløste X11’s netværkstransparens; brug waypipe</strong>, xpra</strong> eller RDP til hurtig fjern-GUI.</li> For den oprindelige motivation — at redigere på en fjern maskine — foretræk VS Codes Remote-SSH, sshfs</a> eller almindelig SSH</a>.</li> </ul> Forlæng videoklip med AI på en 12 GB GPU — seks modeller sammenlignet 2026-06-07T00:00:00+00:00 Kort fortalt —</strong> At “forlænge” et videoklip er i virkeligheden billede-til-video</strong>: tag sidste frame, lad en model generere en troværdig fortsættelse, og sæt dem sammen. Jeg kørte det samme maskine-klip gennem seks</strong> I2V-modeller på ét 12 GB RTX 4070 Ti</strong>: Wan2.2-TI2V-5B, Wan2.2-I2V-A14B (GGUF Q4, ved 640 px og ved 720p), Stable Video Diffusion, LTX-Video og CogVideoX-5B. Pointen er ikke vinderen — men at en 14B</strong>-model og 720p</strong> begge passer i 12 GB, når man får offload-strategien</strong> rigtig.</p> Opgaven</h2> Jeg havde en stak korte klip af skovmaskiner — en gravemaskine, en flishugger, en gummiged — og ville have dem et par sekunder længere. Der er ikke mere materiale; den eneste måde at forlænge på er at opfinde</em> det. Moderne billede-til-video-modeller gør netop det: de betinges på et startbillede (her klippets sidste frame) og en tekst-prompt og hallucinerer bevægelse fremad. Sæt den ægte hale sammen med den genererede fortsættelse, og du har et længere klip.</p> Alt nedenfor kørte lokalt på ét 12 GB RTX 4070 Ti med 125 GB system-RAM (RAM’en betyder noget — det er der de offloadede vægte bor).</p> Det egentlige problem: at få store videomodeller ned i 12 GB</h2> Billed-diffusion er tilgivende på VRAM. Video-diffusion er ikke: man denoiser et 3D-latent (frames × højde × bredde), og de nyeste kvalitetsmodeller er 5B-14B parametre. Tre ting bed hele tiden:</p> Tekstenkoderen er enorm.</strong> Wan, LTX og CogVideoX bruger alle en T5-XXL / umT5-XXL-enkoder på ~11 GB alene. I det øjeblik model-offload flytter den til et 12 GB-kort for at enkode prompten, OOM’er du — før videomodellen overhovedet kører.</li> Aktiveringer, ikke vægte, eksploderer ved højere opløsning.</strong> En 9 GB-transformer kan sidde på kortet fint; det er attention-aktiveringerne over (frames × tokens), der løber over, når man presser forbi ~480p.</li> Kvantisering hjælper på disk og lidt på VRAM, men spiller dårligt sammen med visse offload-tilstande.</strong> GGUF Q4 skrumper en 14B-ekspert til ~9 GB, men hvordan man offloader den betyder noget.</li> </ol> Det der fik det hele til at virke:</p> Præ-enkod prompten på CPU, og smid så enkoderen ud.</strong> Beregn tekst-embeddings med T5 på CPU’en i fp32</em> (bf16-matmuls på CPU er ulideligt langsomme — det ligner at den hænger), cast resultatet til bf16, sæt text_encoder = None</code>, og start så først videomodellen. Nu rører de 11 GB enkoder aldrig GPU’en.</li> Vælg offload-tilstand pr. model:</strong> enable_model_cpu_offload()</code> — flytter hele del-modeller ind/ud af GPU’en. Hurtig, men én model skal kunne være der ad gangen (så den begrænser opløsning/længde).</li> enable_sequential_cpu_offload()</code> — streamer del-moduler. Lavere top-VRAM, langsommere. Glimrende til ikke-kvantiserede modeller (LTX, CogVideoX), men bryder GGUF</strong> (accelerates meta-enhed-trin mister kvant-typen).</li> apply_group_offloading(..., offload_type="leaf_level", use_stream=True)</code> — streamer transformeren blad for blad. Det er hemmelige våben.</li> </ul> </li> </ul> Wan2.2: fra “fake” 5B til ægte 720p</h2> Jeg startede med Wan2.2-TI2V-5B</strong> (den lille, forbrugervenlige). Den kører nemt med model-offload og laver sammenhængende bevægelse, men ved de ~640 px kortet tillader, ser den blød ud — den klassiske plastik-agtige “AI-video”-fornemmelse.</p> At gå op til Wan2.2-I2V-A14B</strong> krævede kvantisering. Den officielle 14B er to eksperter (high-noise + low-noise) og vil have 24-35 GB i fp16. GGUF Q4-versionen er ~9 GB pr. ekspert, og diffusers kan loade hver via WanTransformer3DModel.from_single_file(..., quantization_config=GGUFQuantizationConfig(...))</code> — man skal bare have gguf</code>-pakken, ellers kan filen ikke læses. Med model-offload + CPU-prompt-tricket kører 14B’en ved 640 px, og bevægelsen er synligt bedre (flishuggeren, et kaotisk nærbillede som 5B’en lavede til grød, kom ud sammenhængende).</p> Så det egentlige mål: 720p</strong>. Model-offload ved 1280×720 topper ved ~11,7 GB — den passer, men kun ~13 frames før aktiveringerne løber over. Gennembruddet var group-leaf-offloading</strong>: stream transformeren ét bladmodul ad gangen, så næsten intet sidder på GPU’en. Top-VRAM ved 1280×720: 1,9 GB</strong>. Kortet er pludselig tomt og opløsning er gratis; prisen er hastighed (blad-streaming er langsomt, ~20 min pr. klip). Men det er ægte, skarp 720p på et 12 GB-kort.</p> from diffusers.hooks import apply_group_offloading for t in (pipe.transformer, pipe.transformer_2): # begge støj-eksperter apply_group_offloading(t, onload_device=torch.device("cuda"), offload_device=torch.device("cpu"), offload_type="leaf_level", use_stream=True) pipe.vae.enable_tiling() </code></pre> De andre tre</h2> LTX-Video</strong> (2B). Hurtig og, til korte forlængelser, den bedste af bundtet — dynamisk bevægelse (gravemaskinen kaster jord), prompt-styret, ~3 min pr. klip ved 768×512. Kræver sentencepiece</code> til sin T5-tokenizer, og sequential</code> offload, fordi den T5 er den samme 11 GB OOM-fælde.</li> Stable Video Diffusion</strong> (img2vid-xt). Veteranen. Kører ved 1024×576 med model-offload + unet.enable_forward_chunking()</code>, og den er hurtig — men SVD har ingen tekst-prompt</strong>, så dens bevægelse er ambient</em> (en blid glidning, vind i træerne) frem for den styrede action du bad om. God til filmiske cutaways, forkert værktøj til “bliv ved med at grave”.</li> CogVideoX-5B-I2V</strong>. Kvalitets-overraskelsen: det længste og blødeste klip (6 s, 49 frames ved 720×480), sammenhængende hele vejen. Hagen er hastigheden — med sequential offload + VAE-tiling tager det groft sagt en time pr. klip</strong> på 12 GB, hvilket gør den upraktisk her, selvom outputtet er smukt.</li> </ul> Resultattavlen</h2> Model</th> Parametre</th> Passer i 12 GB via</th> Output</th> Hastighed</th> Dom</th></tr></thead> LTX-Video</td> 2B</td> sequential offload</td> 768×512</td> ~3 min</td> Bedst til korte forlængelser</strong> — hurtig, dynamisk</td></tr> Wan2.2-I2V-14B @ 720p</td> 14B (Q4)</td> group-leaf-offload (1,9 GB!)</strong></td> 1280×720</td> ~20 min</td> Ægte 720p på 12 GB</strong> — skarpest</td></tr> Wan2.2-I2V-14B</td> 14B (Q4)</td> model-offload + CPU-prompt</td> 640×384</td> ~8 min</td> God bevægelse, især de svære tilfælde</td></tr> CogVideoX-5B-I2V</td> 5B</td> sequential + VAE-tiling</td> 720×480</td> ~1 time</td> Længst/blødest, men upraktisk langsom her</td></tr> Stable Video Diffusion</td> ~1,5B</td> model-offload + chunking</td> 1024×576</td> ~2 min</td> Hurtig og ren, men bevægelsen er ambient</td></tr> Wan2.2-TI2V-5B</td> 5B</td> model-offload</td> 640×384</td> ~3 min</td> Den bløde, “fake”-agtige baseline</td></tr> </tbody></table> Hvad jeg faktisk ville gøre</h2> På et 12 GB-kort: grib LTX-Video</strong> til hurtige, styrede forlængelser, og Wan2.2-14B + group-offload</strong> når du specifikt har brug for 720p</strong> og kan vente. SVD bliver i kassen til ambient cutaways. CogVideoX er smuk, men man ville ønske sig en større GPU for at bruge den i praksis.</p> Og den ærlige begrænsning: det der stadig læses som “AI” er mest opløsning</strong>. Group-offload køber dig 720p eller</em> et 12 GB-kort køber dig længde — ikke begge på én gang. Høj opløsning og</em> flere sekunder er den ene mur et 12 GB-kort ikke kan bestige; det er hvad et 24 GB+ kort (eller en time i skyen) er til. Alt andet — selv en 14B-model ved 720p — viste sig at være et spørgsmål om offloading, ikke hestekræfter.</p> Fem måder at skaffe b-roll fra én tur — alt på en lokal GPU 2026-06-02T00:00:00+00:00 Kort fortalt —</strong> B-roll er de klip, der giver en redigering luft, og onboard-POV fra ét kamera har præcis ingen. Jeg tog én ATV-tur og prøvede fem</strong> måder at fabrikere b-roll ud af den: (1) auto-mine</strong> de bedste rigtige frames med OpenCV, (2) generér stills</strong> og seed dem fra rigtige frames med SDXL-Turbo → RealVisXL img2img</strong>, (3) fake et filmisk kamera-move med Depth-Anything-V2</strong>-parallakse i 2,5D, (4) generér ægte bevægelse</em> med Stable Video Diffusion</strong>, og (5) lav et slowmotion</strong>-klip af det rigtige materiale med optisk flow-interpolation. Alt kørte lokalt på et 12 GB RTX 4070 Ti. De supplerer hinanden — her er sammenligningen og fælderne.</p> Problemet</h2> Onboard-materiale — et GoPro/DJI på styret af en gokart eller en ATV — er ét langt førstepersons-shot. Det er fremragende til action, men en redigering har brug for cutaways</em>: etableringsbilledet, naturen, den langsomme detalje, der giver seeren et åndedrag mellem de intense passager. Med ét kamera og intet B-kamera har du ingen. Så: kan man fabrikere troværdig b-roll bagefter, lokalt og gratis?</p> Jeg prøvede fem tilgange på én 11-minutters ATV-tur gennem nordisk skov og grusspor. Hver laver et kort, gradet klip; det interessante er afvejningerne.</p> 1. Auto-mine det rigtige materiale (OpenCV)</h2> Den billigste b-roll er den, du allerede har filmet uden at lægge mærke til det. En lille OpenCV-rutine sampler ~1.400 frames hen over turen og giver hver en score for skarphed</strong> (variansen af Laplacian), farverigdom</strong> (Hasler–Süsstrunk-målet), eksponering</strong> (afstand fra en mellemtone) og bevægelses-stabilitet</strong> (forskel mellem frames — lavt er godt til en stabil cutaway). Non-maximum suppression spreder derefter valgene ud, så du ikke får otte næsten identiske frames fra de samme 20 sekunder.</p> score = 1.1z(skarphed) + 1.0z(farverig) + 0.8z(eksponering) - 0.9rystelse - 6.0klipning </code></pre> Ikke glamourøst, men øjeblikkeligt, gratis og 100 % ægte. Outputtet er din egen tur — bare de mest b-roll-værdige tre sekunder, du havde glemt, du filmede.</p> 2. Generative stills, matchet til den rigtige tur</h2> Her blev det interessant — og her gik det først galt.</p> Forsøg ét: ren text-to-image.</strong> SDXL-Turbo med prompts som “filmisk diset skov i gyldent lys”</em> lavede smukke billeder, der lignede selve turen i ingenting. Forkert lys (solnedgang vs. den rigtige overskyede himmel), ingen ATV i billedet, intet POV. Flot stock-materiale af en</em> skov, ikke denne</em>.</p> Forsøg to: img2img, seedet fra rigtige frames.</strong> Ved at fodre et rigtigt frame ind som init-billede ved moderat denoising-strength bevares den rigtige komposition — den sorte ATV’s styr og spejle i forgrunden, det græs-og-jord-spor, den overskyede palette — og detaljen regenereres. Nu klipper det sammen med det rigtige materiale. Men SDXL-Turbo</strong> ved strength ≈0,5 smeltede</em> stadig: den hallucinerede ekstra instrumenter på instrumentbrættet og forvrængede styret. Det klassiske “AI-look”.</p> Forsøg tre: bedre modeller, lavere strength.</strong> Jeg sammenlignede tre mindre-smeltende metoder på de samme frames:</p> </p> SDXL-base, lav strength (0,30), 30 steps</strong> — tro mod kilden, ingen smelt, men en anelse blød.</li> ControlNet-Canny + SDXL</strong> — låser de rigtige kanter, så intet forvrænger, men komponerede scenen grønnere og mere stiliseret end kilden.</li> RealVisXL</strong> (en fotorealistisk SDXL-finetune), img2img — vinderen: skarp, fotorealistisk, bevarer det rigtige POV og palette, ingen smelt.</li> </ul> </p> Læren: til at matche materiale betyder basismodellen</em> og denoising-strength</em> langt mere end prompten. En fotorealistisk checkpoint ved lav strength slår en prangende destilleret model hver gang.</p> 3. AI Ken Burns — dybde-parallakse</h2> Et stillbillede behøver ikke stå stille. Depth-Anything-V2</strong> estimerer et dybdekort for et frame på et godt stykke under et sekund; med dybde i hånden kan du rendere et 2,5D-kamera-move, hvor nære pixels flytter sig mere end fjerne, plus et blidt skub mod sporets forsvindingspunkt. Det læser som at køre fremad.</p> </p> Hele renderingen er en baglæns cv2.remap</code> med dybdevægtet forskydning, så den er hulfri og hurtig. Én fælde værd at notere: OpenCV’s remap</code> vil have float32</code>-maps, og en enkelt løs Python-skalar i regnestykket opgraderer dem stille til float64</code>, hvorefter remap</code> fejler. Cast dem eksplicit tilbage til float32</code>.</p> Det er den bedste indsats-per-effekt af de syntetiske muligheder: rigtigt indhold, ægte-udseende bevægelse, en lillebitte model. Den eneste begrænsning er, at store skub begynder at afsløre forvrængning ved dybde-spring — hold bevægelsen diskret.</p> 4. Generativ video — Stable Video Diffusion</h2> Vil du have bevægelse, som et stillbillede ikke</em> kan fake, animerer Stable Video Diffusion</strong> (image-to-video) et stillbillede til ægte bevægelse — kameraet driver og skubber gennem scenen, parallakse og det hele, opfundet af modellen frem for forvrænget geometrisk.</p> </p> At seede SVD fra RealVisXL-stillsene giver genereret bevægelse, der stadig ligner turen. De ærlige forbehold: klippene er korte (~2–3 sekunder ved 25 frames), bevægelsen er kun løst styrbar (du nudger den med en “motion bucket”, ikke en bane), og der er let kant-forvrængning. Det er også det tungeste her — modellen fylder ~9 GB og passer på et 12 GB-kort kun med CPU-offload, UNet forward-chunking og en lille VAE-decode-chunk:</p> pipe.enable_model_cpu_offload() pipe.unet.enable_forward_chunking() frames = pipe(image, num_frames=25, decode_chunk_size=2, motion_bucket_id=110, noise_aug_strength=0.04).frames[0] </code></pre> 5. Filmisk slowmotion — rigtigt materiale, ingen AI</h2> Den femte mulighed bruger slet ingen generativ model. Tag de auto-minede øjeblikke, sæt dem ned til 50 % fart med bevægelseskompenseret optisk-flow-interpolation</strong> (så slowmotion bliver glat, ikke hakkende duplikerede frames), stabilisér let, og læg en filmisk grade på. ffmpeg klarer det i én filterkæde:</p> minterpolate=mi_mode=mci:mc_mode=aobmc:me_mode=bidir:vsbmc=1:fps=60,setpts=2.0PTS </code></pre> Det er 100 % ægte, ser dyrt ud og er det mest “broadcast” af det hele. Interpolation kan udtvære meget hurtige kanter, men på naturklip er det rent.</p> Hvilken vinder?</h2> Ingen — de supplerer hinanden, og en rigtig redigering blander flere:</p> Metode</th> Ægthed</th> Kontrol</th> Omkostning</th> Bedst til</th></tr></thead> 1 · Auto-mine (CV)</td> Ægte</td> Begrænset til det filmede</td> Øjeblikkelig</td> Ægte cutaways, gratis</td></tr> 2 · Generative stills (RealVisXL)</td> Syntetisk</td> Høj (enhver scene)</td> Mellem (GPU)</td> Shots du aldrig filmede</td></tr> 3 · Dybde-parallakse</td> Ægte + fake bevægelse</td> Kun bevægelse</td> Billig</td> At gøre et godt frame levende</td></tr> 4 · SVD-video</td> Syntetisk</td> Løs bevægelse</td> Tungest (~9 GB)</td> Levende bevægelse uden materiale</td></tr> 5 · Slowmotion (ægte)</td> 100 % ægte</td> Fart/grade</td> Mellem</td> Et dyrt klip af ægte øjeblikke</td></tr> </tbody></table> Hvis jeg skulle levere ét b-roll-lag til den slags materiale, blev det slowmotion (5) for den ægte, dyre følelse</strong>, med dybde-parallakse (3)</strong> til at lægge bevægelse på fremtrædende frames, og RealVisXL-stills (2)</strong> kun dér, hvor jeg har brug for et etableringsbillede, der aldrig kunne filmes.</p> Stak</h2> GPU:</strong> ét RTX 4070 Ti, 12 GB</strong>. Alt nedenstående passer.</li> Diffusion:</strong> diffusers</code> 0.38 — SDXL-base, RealVisXL V4.0</strong>, ControlNet-Canny-SDXL, Stable Video Diffusion XT</strong>.</li> Dybde:</strong> transformers</code> + Depth-Anything-V2-Small</strong>.</li> CV / samling:</strong> OpenCV, NumPy og ffmpeg</strong> (minterpolate</code>, deshake</code>, AV1 NVENC, AVIF-stills).</li> Et par fælder værd at huske: en distro-Python markeret PEP 668 externally-managed</strong> vil stille</em> nægte pip install</code> — brug et rigtigt virtualenv. Og pgrep -f build.sh</code> matcher glad og gerne den watcher-kommando</em>, der indeholder strengen, så stol ikke på den til at fortælle dig, at en rendering er færdig; tjek efter en levende ffmpeg</code> i stedet.</li> </ul> Hvorfor det findes</h2> Det startede som “onboard-klippene mangler cutaways, og jeg har ét kamera”. Det ærlige svar viste sig at være, at du ikke behøver et andet kamera — du skal finde</em> den b-roll, du allerede har filmet (1, 5), og fabrikere</em> resten med den mindste model, der gør arbejdet (3 før 2 før 4). Den mest prangende mulighed (generativ video) er den, jeg ville gribe til sidst. Den mindst prangende (at score frames med en Laplacian) er den, jeg ville gribe først.</p> Alt lokalt, alt på et kort, der koster mindre end en weekend med cloud-GPU. Ikke interessant før du har brug for det — og så er det præcis det, du har brug for.</p> Sammensætning af drone-panoramaer: OpenCV vs Hugin, benchmarket 2026-05-31T00:00:00+00:00 TL;DR —</strong> Jeg havde en mappe med 63 DJI Phantom 4 Pro-billeder taget over Randers og ville lave panoramaer ud af dem. Jeg sammensatte de samme sweeps på to måder: OpenCVs Stitcher</code></strong> (fuldautomatisk, sfærisk) og Hugins kommandolinje-pipeline</strong> (cpfind</code> → autooptimiser</code> → nona</code> → enblend</code>). OpenCV er hurtig (få sekunder) og beholder det bredeste synsfelt, men horisonten bliver bølget, kanterne flossede, og eksponeringssømmene er synlige. Hugin tager ~30 s pr. panorama, men giver en lige horisont, sømløs multi-band-overgang og et rent rektangulært beskåret billede</strong>. Til alt, du vil printe eller udgive, vinder Hugin. Alle kommandoer og en benchmark-tabel nedenfor.</p> Udgangspunktet</h2> En mappe, 63 filer, DJI_0029.jpeg</code> til DJI_0091.jpeg</code>, ~15 MB hver, 5464 × 3070 px. Ingen flylog, ingen projektfil, og — som det viste sig — det meste af de brugbare metadata fjernet. Bare JPEG-filer og en enlig result.jpg</code> fra et tidligere forsøg.</p> Første opgave: finde ud af hvad disse billeder egentlig er</em>, før jeg beslutter, hvordan de skal sammensættes. Er det et nadir-kortlægningsgitter? Ét enkelt rotations-panorama? Flere separate sweeps? Hver af dem sammensætter man forskelligt.</p> At regne optagelsen ud fra metadata</h2> Ingen exiftool</code> på maskinen, så:</p> sudo apt-get install -y libimage-exiftool-perl imagemagick </code></pre> DJI skriver normalt gimbal-yaw/pitch/roll ind i et XMP-namespace, som ville fortælle mig præcis, hvordan kameraet pegede for hvert billede. Her var det fjernet — filerne var tydeligvis blevet re-eksporteret på et tidspunkt (hvilket også forklarer den root-ejede result.jpg</code>). Det, der overlevede, var GPS og tidsstempler:</p> exiftool -n -T -FileName -GPSLatitude -GPSLongitude -GPSAltitude \ -SubSecDateTimeOriginal DJI_.jpeg </code></pre> To ting sprang straks i øjnene.</p> Der var to sessioner, 90 minutter fra hinanden:</strong></p> 0029</code>–0054</code>, taget 09:01–09:15</li> 0055</code>–0091</code>, taget 10:31–10:36</li> </ul> Den anden session var en stak vandrette sweeps i stigende højde.</strong> GPS-positionen flyttede sig næsten ikke, mens højden steg i tydelige bånd — 169 m, så 221 m, så 240 m, så 269 m. Det er signaturen på en drone, der svæver på stedet og panorerer kameraet hen over horisonten i hver højde. Hvert højdebånd er ét panorama.</p> Et hurtigt kontaktark bekræftede det:</p> ls DJI_.jpeg \| sed 's/.jpeg//' \| xargs -P4 -I{} \ convert {}.jpeg -resize 260x -gravity South -background black \ -splice 0x16 -pointsize 13 -fill yellow -annotate +0+1 '{}' /tmp/thumbs/{}.png montage /tmp/thumbs/DJI_00{55..91}.png -tile 6x -geometry +3+3 /tmp/sheet.png </code></pre> Session ét viste sig at være blandet — billeder lige ned på en enkelt ejendom i forskellige højder (en lodret zoom-sekvens, ikke et panorama) plus nogle skrå nabolagsoptagelser. Så jeg fokuserede panoramaerne på session to’s sweeps, som tydeligvis var det, dronen var der for at fange.</p> De grupper, jeg endte med:</p> Gruppe</th> Billeder</th> Højde</th> Indhold</th></tr></thead> A</td> 0055–0065</td> ~169 m</td> Villakvarter, lav panorering</td></tr> B</td> 0066–0076</td> ~221 m</td> By</td></tr> C+D</td> 0077–0091</td> 240–269 m</td> Høj skyline</td></tr> </tbody></table> Teknik 1 — OpenCV Stitcher</h2> Vejen med mindst modstand. OpenCV leverer en Stitcher</code> på højt niveau, der klarer feature-detektion, matchning, bundle adjustment, warping og blending i ét kald.</p> pip install opencv-contrib-python numpy </code></pre> import cv2, glob imgs = [cv2.imread(f) for f in sorted(glob.glob("group_A/.jpg"))] stitcher = cv2.Stitcher_create(cv2.Stitcher_PANORAMA) # sfærisk model status, pano = stitcher.stitch(imgs) if status == cv2.Stitcher_OK: cv2.imwrite("A_opencv.jpg", pano) </code></pre> To tilstande er vigtige:</p> PANORAMA</code></strong> antager, at kameraet roterede om sit optiske centrum (sfærisk warp). Korrekt for disse svæv-og-panorer-sweeps.</li> SCANS</code></strong> antager en affin/translatorisk model (flatbed-scanninger, nadir-kortlægning). Jeg prøvede den for fuldstændighedens skyld; den er den forkerte model her og reducerede de fleste sweeps til to-tre billeder. Brug den ikke til roterende luftoptagelser.</li> </ul> Jeg kørte alt på et 2400 px-arbejdssæt først — fuld opløsning er langsom at iterere på, og man vil gerne se, om en gruppe overhovedet hænger sammen, før man bruger minutter på den.</p> Dom over OpenCV:</strong> den bare virker, med nul parametre, på sekunder. Gruppe A — elleve billeder — blev til et 10433 × 1595-panorama på cirka 5 sekunder. Hagen er resultatet: en bølget horisont</strong>, flossede revne kanter</strong>, man selv skal beskære, og svage eksponeringssømme</strong>, hvor billeder mødes. Fint til et hurtigt kig; ikke noget, man printer.</p> Teknik 2 — Hugin-pipelinen</h2> Hugin</a> er open source-panoramaværktøjet, og afgørende er hele dets motor scriptbar fra kommandolinjen — ingen GUI nødvendig.</p> sudo apt-get install -y hugin-tools enblend enfuse </code></pre> Pipelinen, trin for trin:</p> pto_gen -o p.pto DJI_0055.jpeg ... DJI_0065.jpeg # 1. projekt fra EXIF cpfind --multirow -o p.pto p.pto # 2. find kontrolpunkter cpclean -o p.pto p.pto # 3. fjern dårlige matches autooptimiser -a -m -l -s -o p.pto p.pto # 4. optimér + ret horisont pano_modify --canvas=AUTO --crop=AUTO --projection=2 \ -o p.pto p.pto # 5. cylindrisk + auto-beskær nona -m TIFF_m -z LZW -o remap p.pto # 6. remap hvert billede enblend -o pano.tif remap.tif # 7. multi-band-overgang </code></pre> Hvad hvert trin giver dig ud over OpenCV-onelineren:</p> cpfind --multirow</code></strong> finder ordentlige kontrolpunkter på tværs af hele sættet — den rapporterede 250, 302 og 718 punkter for gruppe A, B og C+D.</li> autooptimiser -l -s</code></strong> retter horisonten og opretter panoramaet. Det er den største synlige gevinst: bølgen forsvinder.</li> --projection=2</code></strong> er cylindrisk, hvilket holder horisonten som en lige vandret linje — præcis hvad man vil have til et bredt luft-sweep.</li> --crop=AUTO</code></strong> beskærer til det største rene rektangel, så ingen manuel beskæring.</li> enblend</code></strong> laver multi-band (Burt–Adelson)-blending, som skjuler de eksponeringsforskelle mellem billeder, OpenCV efterlod synlige.</li> </ul> Samme gruppe, to pipelines, stablet — OpenCV øverst, Hugin nederst:</p> </p> Forskellen er ikke subtil.</p> Benchmarken</h2> Samme inputgrupper, begge pipelines. OpenCV-tallene er 2400 px-arbejdssættet; Hugin-tallene er de endelige kørsler i fuld opløsning på 5464 px.</p> Gruppe</th> Billeder</th> Værktøj</th> Resultat</th> Tid</th> Horisont</th> Overgang</th> Beskæring</th></tr></thead> A · villakvarter</td> 11</td> OpenCV PANORAMA</td> 10433 × 1595</td> 5 s</td> bølget</td> sømme</td> flosset</td></tr> A · villakvarter</td> 11</td> Hugin + enblend</strong></td> 11581 × 1827</td> 31 s</td> lige</strong></td> sømløs</strong></td> ren</strong></td></tr> B · by</td> 11</td> OpenCV PANORAMA</td> 10295 × 1838</td> 11 s</td> bølget</td> sømme</td> flosset</td></tr> B · by</td> 11</td> Hugin + enblend</strong></td> 8190 × 2547</td> 30 s</td> lige</strong></td> sømløs</strong></td> ren</strong></td></tr> C+D · skyline</td> 15</td> OpenCV PANORAMA</td> 8660 × 1975</td> 2 s</td> bølget</td> sømme</td> flosset</td></tr> C+D · skyline</td> 15</td> Hugin + enblend</strong></td> 22469 × 2391</td> 60 s</td> lige</strong></td> sømløs</strong></td> ren</strong></td></tr> </tbody></table> OpenCV er 3–10× hurtigere og beholder typisk et bredere synsfelt (den warper og beholder de revne kanter i stedet for at beskære dem). Hugin er langsommere, men vinder på hver kvalitetsakse, der betyder noget for et færdigt billede.</p> Op i fuld opløsning</h2> Da Hugin var den klare vinder, kørte jeg den igen på de originale 5464 px-billeder. Pipelinen er identisk — peg bare pto_gen</code> på de originale JPEG-filer i stedet for det nedskalerede sæt. cpfind</code> og enblend</code> er de langsomme trin ved fuld opløsning, men det lå stadig omkring 30 s pr. panorama, et minut for skyline-billedet med 15 frames.</p> De færdige panoramaer:</p> Den høje skyline — femten billeder, 22469 × 2391, et næsten 180° sweep hen over hele byen:</strong></p> </p> Villakvarter-sweepet i 169 m:</strong></p> </p> Byen i 221 m:</strong></p> </p> Ved 22469 px bredde kan skyline-billedet uden problemer printes i storformat.</p> FAQ</h2> Hvorfor betød metadataene så meget — hvorfor ikke bare smide alle 63 ind i stitcheren?</h3> Det kan man godt, og OpenCV vil forsøge at finde sammenhængende komponenter. Men filerne var to urelaterede sessioner plus en blanding af nadir- og skråbilleder. At fodre det hele ind risikerer, at optimeringen forbinder billeder, der ikke bør hænge sammen, eller spilder minutter på at fejle. Fem minutter med exiftool</code> til at gruppere billederne først sparede en masse gætteri — og fortalte mig, hvilke</em> grupper der overhovedet var panoramaer.</p> Hvorfor ikke bare bruge dronens indbyggede panorama-funktion?</h3> Disse var ikke taget som in-camera-panoramaer — det er enkeltbilleder fra manuelle sweeps, og den indbyggede sammensætning (hvis den overhovedet kørte) er den lavopløselige result.jpg</code>, jeg fandt i mappen. At sammensætte fra de originale fuldopløselige billeder giver langt mere detalje end in-camera-JPEG’en.</p> Hvad med PTGui / Lightroom / Microsoft ICE?</h3> Alle dygtige. PTGui er i bund og grund kommerciel Hugin og fremragende. Lightrooms Photo Merge er praktisk, hvis du allerede er derinde. Microsoft ICE var god, men er udgået. Jeg ville have en scriptbar, gratis, Linux-native pipeline, jeg kunne køre headless over en mappe — det er Hugin.</p> Cylindrisk, sfærisk eller rektilineær?</h3> Til et bredt vandret sweep holder cylindrisk</strong> (--projection=2</code>) horisonten lige og håndterer >120° uden den ekstreme strækning, rektilineær giver i kanterne. Sfærisk (det OpenCVs PANORAMA</code> bruger) er også fint, men har tendens til at bue horisonten, medmindre pitchen er godt estimeret — hvilket er sværere her, fordi gimbal-vinklerne var fjernet.</p> Kan det køre uovervåget over en hel mappe?</h3> Ja — hele Hugin-vejen er CLI, så den passer direkte ind i et shell-script eller en Makefile</code>. Gruppér billederne (efter tidsstempel/højde, eller lad bare cpfind</code> finde sammenhængende komponenter), og loop så de syv kommandoer pr. gruppe. Det er det egentlige argument for Hugin frem for et GUI-værktøj her.</p> Dom</h2> Vil du have et panorama nu</em> og er ligeglad med en bølget horisont eller selv at trimme kanter, er OpenCVs Stitcher</code> en fem-sekunders oneliner og oprigtigt imponerende for indsatsen.</p> Til alt, du beholder — print, udgivelse, på væggen — er Hugins kommandolinje-pipeline</strong> det ekstra halve minut værd. En lige horisont, en sømløs overgang og en automatisk ren beskæring er præcis de ting, der adskiller et snapshot fra et færdigt panorama, og Hugin leverer alle tre gratis. Det er nu mit standardvalg til at sammensætte alt fra dronen.</p> Det hele — fra installation til færdige fuldopløselige panoramaer — tog cirka en time, det meste brugt på at forstå billederne frem for at sammensætte dem. Hvilket som regel er sådan, det går.</p> bchunk — konverter .bin/.cue-images til .iso og .wav på Linux og macOS 2026-04-22T00:00:00+00:00 TL;DR —</strong> bchunk</code></strong> — også kaldet binchunker</code></strong> — er et lille, gammelt Unix-kommandolinjeværktøj, der tager et .bin</code>/.cue</code>-par (et råt cd-image med et cue-sheet) og deler det op i en rigtig .iso</code>-fil til datasporet</strong> og én .wav</code>-fil pr. lydspor</strong>. Det er det rigtige værktøj, når et download eller arkiv har givet dig game.bin</code> + game.cue</code>, og du faktisk vil mounte datasporet</strong> eller brænde lydsporene</strong> igen. Installeres med apt install bchunk</code> på Debian/Ubuntu, brew install bchunk</code> på macOS eller bygges fra kilden på alt andet. Brug er bchunk [options] image.bin image.cue basename</code> — du får basename01.iso</code>, basename02.wav</code>, basename03.wav</code> osv.</p> Hvad .bin/.cue er, og hvorfor du vil splitte det</h2> Et .bin</code>/.cue</code>-par er et råt, bit-nøjagtigt cd-image</strong> plus et klartekst-sheet, der beskriver sporenes layout. .bin</code> indeholder hver sektor af cd’en i rækkefølge — inklusive datasport (Mode 1 eller Mode 2), lydspor (rå Red Book PCM, 2352 bytes pr. sektor, intet filsystem) og pauserne imellem dem. .cue</code> fortæller, hvor hvert spor begynder, og hvilken type det er.</p> Formatet er standard-output for cd-ripning-værktøjer som cdrdao og for gamle spil-arkiver, fordi det bevarer alt</em> — pregaps, CD-TEXT, mixed-mode-cd’er, CD-DA-lyd. Det er også grunden til, at du ikke bare kan omdøbe game.bin</code> til game.iso</code> og mounte det: en mixed-mode-cd har ikke-filsystem-sektorer</strong> i starten, lydspor der slet ikke er filsystem, og per-sektor-headers, som ISO forventer fjernet.</p> bchunk</code> laver konverteringen rigtigt:</p> Datasport</strong> bliver til ISO 9660-filer (.iso</code>) — 2352-byte cd-sektorer bliver trimmet til 2048-byte ISO-sektorer, headers smidt væk.</li> Lydspor</strong> bliver til 16-bit stereo 44,1 kHz .wav</code>-filer, hver med en ordentlig WAV-header.</li> </ul> Derefter kan du mount -o loop</code> .iso</code>’en, afspille .wav</code>’erne eller fodre dem til en brænder.</p> Installation</h2> Debian / Ubuntu / Mint</h3> sudo apt install bchunk </code></pre> macOS (Homebrew)</h3> brew install bchunk </code></pre> Arch / Manjaro</h3> sudo pacman -S bchunk # eller fra AUR: yay -S bchunk </code></pre> Fedora / RHEL / CentOS</h3> bchunk</code> er ikke i standard-repoet; hent det fra RPMFusion eller byg fra kilden:</p> git clone https://github.com/hessu/bchunk.git cd bchunk make sudo cp bchunk /usr/local/bin/ </code></pre> Windows</h3> Brug WSL og apt install bchunk</code>. Der findes en gammel native port, men WSL er nemmere.</p> Grundlæggende brug</h2> bchunk game.bin game.cue game </code></pre> Output:</p> game01.iso # datasport, mountbart som ISO 9660 game02.wav # lydspor 1 game03.wav # lydspor 2 ... </code></pre> basename</code> (game</code> i eksemplet) er præfikset for hver output-fil. Spornumre starter ved 01</code>.</p> Nyttige options</h2> bchunk</code> har et lille, stabilt sæt flag — de fleste er der for at håndtere specifikke cd-særheder.</p> -v</code></strong> — verbose. Printer hvert spor, efterhånden som det behandles. Brug den første gang, du kører det, for at bekræfte, at du får det sporlayout, du forventer.</li> -w</code></strong> — skriv .wav</code>-filer (default). Eksplicit form.</li> -r</code></strong> — rå lydoutput i stedet for .wav</code>. Nyttigt hvis du piper ind i sox</code> eller ffmpeg</code> og ikke vil have et ekstra header-skrællende skridt.</li> -p</code></strong> — Psx/PlayStation-mode</strong>. Behandler Mode 2-sektorer mere løst — nødvendigt for mange PlayStation-cd-images, hvor cue-sheetet er upræcist.</li> -s</code></strong> — byt byte-rækkefølge på lydspor. Nødvendigt hvis .bin</code>’en er produceret af en ripper, der skrev little-endian-lyd, hvor bchunk</code> forventer big-endian (eller omvendt). Symptom: output-.wav</code> lyder som hvid støj.</li> -W</code></strong> — skriv .wav</code> med en verificeret (i stedet for beregnet) header-størrelse. Sjældent nødvendigt.</li> -E</code></strong> — brug de nøjagtige spor-grænser fra cue-sheetet i stedet for at prøve sig frem. Brug dette hvis lydspor lyder klippet i starten eller slutningen.</li> </ul> Mount af den resulterende .iso</h2> På Linux:</p> sudo mkdir /mnt/cd sudo mount -o loop game01.iso /mnt/cd ls /mnt/cd </code></pre> På macOS:</p> hdiutil attach game01.iso </code></pre> Almindelige faldgruber</h2> “Illegal or unsupported track type” eller tomt output</h3> Dit cue-sheet er malformet eller refererer til en .bin</code>-størrelse, der ikke matcher. Åbn .cue</code>’en i en teksteditor — den er klartekst — og tjek:</p> FILE "..."</code>-linjen peger på det rigtige .bin</code>-filnavn, case-sensitivt.</li> TRACK</code>-entries er nummereret sekventielt med typerne MODE1/2352</code>, MODE2/2352</code> eller AUDIO</code>.</li> Index-entries (INDEX 00</code>, INDEX 01</code>) er MM:SS:FF, hvor FF er frames (0–74).</li> </ul> Lydspor lyder som statisk</h3> Byte-rækkefølge-mismatch. Prøv igen med -s</code>:</p> bchunk -s game.bin game.cue game </code></pre> Enkelt .iso</code> er fin, men lydspor er stille eller afkortede</h3> Prøv -E</code> for at tvinge cue-sheet-eksakte grænser:</p> bchunk -E game.bin game.cue game </code></pre> PlayStation/PSX-image splitter ikke rent</h3> Brug -p</code>:</p> bchunk -p psx.bin psx.cue psx </code></pre> Det er den mest almindelige klage på fora — PSX-cues er næsten altid Mode 2, og bchunk</code> uden -p</code> er streng overfor dem.</p> Flere .bin</code>-filer refereret i cue-sheetet</h3> Nogle rippere producerer én .bin</code> pr. spor plus et samlende cue-sheet. bchunk</code> forventer én .bin</code> for hele skiven. Concatener dem først med cat track01.bin track02.bin ... > combined.bin</code> og peg et single-file-cue på combined.bin</code>.</p> Alternativer værd at kende</h2> cdemu</code></strong> — user-space cd-emulator til Linux. Kan mounte en .bin</code>/.cue</code> direkte uden at splitte. Nyttigt, hvis du bare vil læse</em> datasporet midlertidigt.</li> ecm-tools</code></strong> — andet format (.ecm</code>), men samme problemområde. Værd at kende, hvis du støder på det.</li> 7z</code> / p7zip</code></strong> — nyere 7-Zip-versioner kan liste og uddrage ISO 9660-datasport fra en rå .bin</code>, men kan ikke redde lyd som .wav</code>.</li> ffmpeg</code></strong> — hvis du vil have MP3 / FLAC / Opus i stedet for .wav</code>, pipe rå-outputtet: bchunk -r game.bin game.cue game && ffmpeg -f s16be -ar 44100 -ac 2 -i game02.raw game02.flac</code>.</li> </ul> Hvorfor det stadig er nyttigt i 2026</h2> Optisk-medie-imaging har været et løst problem i årtier, men .bin</code>/.cue</code> er stadig default-output fra cdrdao</code>, stadig det gamle arkiver er lagret som, og stadig det, der dukker op, når nogen rækker dig en cd-backup, der ikke er en ISO. bchunk</code> er et ~1.000-liniers C-program, skrevet i sen-1990’erne, der gør ét job korrekt og knap har ændret sig i tyve år. Det er i alle store distributioner, det kompilerer rent på moderne systemer, og det er det rigtige værktøj.</p> Hvis du prøver at redde data fra et gammelt cd-image: start her.</p> binlist.net — hvordan et ferie-sideprojekt fra Fuerteventura blev til iinlist.com 2026-04-22T00:00:00+00:00 TL;DR —</strong> binlist.net</a> er en gratis HTTP-API</strong>, der tager de første 6–8 cifre af et kortnummer (BIN</strong> eller IIN</strong>) og returnerer udsteder-bank, land, kort-netværk (Visa, Mastercard osv.), korttype (debit/credit/prepaid) og kategori. Jeg startede den i august 2013 på ferie på Fuerteventura</strong>, fordi jeg skulle bruge BIN-opslag til et andet projekt, og alt der fandtes var enten betalingspligtigt, forældet eller bag en tvivlsom scraper. Det var mit første Go-projekt nogensinde</strong>, ramte 100.000 queries/dag</strong> inden for uger og krydsede 1 million queries/dag i 2015</strong>. Den er stadig online, stadig gratis, stadig curl</code>-venlig. Den kommercielle variant, iinlist.com</a>, er den, jeg medstiftede efter binlist.nets succes; det er samme idé med betalingsindustri-præcision</strong>, 8-cifret IIN-understøttelse</strong> (påkrævet af ISO/IEC 7812 siden 2022), ARDEF-baserede ranges</strong> og en SLA — bygget til banker, PSP’er, fraud-teams og issuere, der har brug for at behandle BIN-data som produktions-data.</p> BIN vs IIN — et grundkursus på én paragraf</h2> De første seks (historisk) eller otte (siden 2017, obligatorisk fra 2022) cifre af et kortnummer er Issuer Identification Number</strong> (IIN). Det gamle navn, stadig vidt brugt, er Bank Identification Number</strong> (BIN). Givet en BIN/IIN kan du afgøre:</p> Netværk</strong> — Visa, Mastercard, Amex, Discover, JCB, UnionPay, Diners.</li> Udsteder</strong> — banken eller fintech’en, der udstedte kortet.</li> Land</strong> — udstederens land, ikke nødvendigvis kortholderens, men en nyttig proxy for risiko-scoring, skatte-logik (EU/EØS moms-OSS) og brugeroplevelse (foretrukket sprog, lokale betalingsmetoder).</li> Type</strong> — debit, credit, prepaid, deferred debit, charge.</li> Kategori / produkt</strong> — Classic, Gold, Platinum, Business, Corporate osv. Nyttigt til acceptance-cost-routing (erhvervskort koster mere at modtage).</li> </ul> Alt dette er “følsomt” i den forstand, at udstedere ikke offentliggør fulde BIN-tabeller, og kort-netværkene betragter dem som proprietære. I praksis lækker BIN-ranges konstant — hver autorisation, netværket router, hver chargeback-dispute — og der er en hel bibranche omkring at holde rimeligt præcise BIN-tabeller.</p> Hvorfor jeg byggede binlist.net på ferie</h2> Sommer 2013. Playitas, sydlige Fuerteventura</strong> — resortet på Atlanterhavs-siden nede ved Gran Tarajal. Lejet lejlighed, lille balkon, kanariefuglevinden gør sit. Jeg havde en idé til et sideprojekt, der skulle slå kort op via BIN, og jeg ville ikke betale en betalings-leverandør €200/md for det. De eksisterende gratis muligheder var:</p> Wikipedias IIN-liste</strong> — rimelig præcis for velkendte netværk, elendig dækning for niche-udstedere, opdateret af frivillige, der ikke arbejder i payments.</li> Indsatte CSV’er på fora</strong> — anstændig dækning for US-udstedere, altid forældet.</li> Google Fusion Tables</strong> — udfaset af Google samme år.</li> Scrapere af merchant-bankers opslagsformer</strong> — ToS-overtrædende, skrøbelige.</li> </ul> Det jeg ville have, var curl http://example.com/40012345</code> der returnerer ren JSON. Så jeg byggede det.</p> Stakken (dengang)</h3> Det var mit første Go-projekt nogensinde</strong>. Jeg havde læst om Go et stykke tid og ville have en lille, velafgrænset undskyldning for at prøve det; en single-endpoint JSON-API over en in-memory BIN-tabel var perfekt. Ruby/Sinatra ville have været hurtigere at taste for mig, men jeg ville lære noget, og memory- og latency-karakteristikken af en Go-binary viste sig at være præcis det, en gratis-tier offentlig API havde brug for.</p> Go</strong> — en enkelt binary, net/http</code>, ingen framework. Hele serveren fyldte nogle hundrede linjer.</li> In-memory BIN-range-tabel</strong>, bygget ved boot fra en ~300 MB kilde-fil. Opslag var O(log n) over et sorteret slice.</li> Deployet på én Hetzner-VM</strong> fra dag ét (jeg overvejede kortvarigt Heroku, men Heroku’s gratis dyno-memory-grænser kunne ikke rumme en fuldt indlæst BIN-tabel).</li> JSON + XML + CSV</strong>-svarformater, fordi 2013.</li> Dataseed</strong> fra en kombination af offentlige Wikipedia-scrapes, den gamle “Mars Base”-CSV fra 2009 og et sæt ranges, jeg havde akkumuleret på arbejde.</li> </ul> Samlet build-tid på den balkon: en weekend — hvoraf cirka halvdelen var mig, der fandt ud af go build</code>, GOPATH</code> (Go-moduler fandtes ikke endnu) og hvordan interfaces virkede. Jeg købte domænet mandag morgen, deployede binaryen og tweetede om det.</p> Trafik-kurven</h3> Uge 1:</strong> et par hundrede queries/dag, mest mig, der testede.</li> Måned 1:</strong> ~100.000 queries/dag</strong>, efter udviklere på Stack Overflow og et par e-handels-fora fandt den.</li> I begyndelsen af 2015:</strong> krydsede 1 million queries/dag</strong> vedholdende, med spikes over 2M under flash-sale-events hos merchants, der kaldte den på hver checkout-page-load.</li> </ul> At skalere til det punkt kostede næsten ingenting, fordi Go’s single-binary-fodaftryk betød, at en ~€5/md VPS klarede det hele; flaskehalsen var længe NIC’en, ikke CPU eller memory.</p> 13 år senere</h3> binlist.net kører stadig. Den er blevet flyttet infrastruktur nogle gange — Hetzner-VM → Hetzner-flåde → en lille flåde bag Cloudflare — og dataseed’et er blevet opdateret løbende, men API-overfladen (og det meste af den oprindelige Go-kode) er den samme. I dag serverer den titusinder af millioner opslag pr. måned</strong>, gratis, uden API-nøgle, med en soft-rate-limit på anonyme kaldere for at holde den ærlig.</p> Den har ~2.000 Google-visninger/md</strong> for queries som “binlist”, “bin list bank identification number”, “list of bank identification numbers” — den samler stadig den lange hale af udviklere op, der skriver samme spørgsmål, jeg skrev i Google i 2013.</p> Hvorfor iinlist.com findes</h2> binlist.nets data er god nok til “hvilket land er dette kort fra”-beslutninger — risiko-scoring, valuta-præsentation, analytics. Den er ikke</strong> god nok til:</p> Acceptance-cost-routing</strong>, hvor du router erhvervskorts-transaktioner gennem en anden processor.</li> Interchange++-modellering</strong>, hvor margin-forskellen mellem Classic og Platinum Mastercard er rigtige penge.</li> Compliance</strong> — ISO/IEC 7812-migrationen fra 6-cifrede BIN’er til 8-cifrede IIN’er, obligatorisk fra 2022, brød en masse “jeg bruger bare de første seks cifre”-logik.</li> Co-badged kort</strong> (f.eks. Dankort + Visa Debit), hvor to netværk begge hævder kortet, og routing-beslutningen er forretningskritisk.</li> ARDEF-præcision</strong> — Visas Account Range Definition File er sandhedskilden; du vil virkelig have data afledt af ARDEF til noget, der kører i produktion.</li> </ul> iinlist.com løser det, kommercielt. Jeg medstiftede den med et lille team af folk, der kender payments-data professionelt. Det er produktet, som binlist.net er gratis-tier-annoncen for. Nogle af vores kunder er navne, du ville genkende; de fleste er ikke. De kommer alle til samme konklusion: BIN-data der er “stort set rigtige” koster mere i forkerte beslutninger, end præcise data koster i licens-gebyr</strong>.</p> Hvad iinlist.com specifikt er</h3> 8-cifret IIN-understøttelse</strong> på tværs af alle netværk.</li> Daglige opdateringer</strong> afledt af ARDEF + netværks-feeds + udsteder-annonceringer + intern verificering.</li> Rigere enrichment</strong>: korttype, produkt-kategori, udsteder-land, udsteder-branding, regulatoriske klassifikationer (commercial vs consumer, prepaid-flag osv.).</li> SLA og support</strong>. Du kan oprette en ticket, og den når faktisk et menneske.</li> On-prem / self-hosted</strong>-mulighed for kunder, hvis compliance ikke tillader “BIN-opslag som tredjeparts-API-kald i autorisations-stien”.</li> Prissætning</strong> der giver mening for både en startende fintech (månedlig plan) og en etableret acquirer (årlig, ubegrænset).</li> </ul> Kan jeg bare bruge binlist.net kommercielt?</h2> Du kan bruge binlist.net, som du vil; der er ingen gate. Men:</p> Ingen SLA, ingen oppetidsgaranti, ingen kontrakt. Det er et sideprojekt, der er blevet oppe i 13 år.</li> Rate-limits på anonym trafik træder i kraft ved produktions-volumen. Køb en licens fra iinlist.com, og problemet er løst.</li> Hvis din regulator spørger, hvor dine BIN-data kommer fra, er “en gratis API, min udvikler fandt” ikke det svar, du vil give.</li> </ul> Til hobby, demo eller prototype: binlist.net er perfekt. Til alt, hvor forkerte BIN-data bliver en KPI: iinlist.com.</p> Brug af binlist.net i dag</h2> $ curl -sH "Accept-Version: 3" https://lookup.binlist.net/45717360 { "number": { "length": 16, "luhn": true }, "scheme": "visa", "type": "debit", "brand": "Visa/Dankort", "country": { "numeric": "208", "alpha2": "DK", "name": "Denmark", "emoji": "🇩🇰", "currency": "DKK", "latitude": 56, "longitude": 10 }, "bank": { "name": "Jyske Bank A/S", "url": "www.jyskebank.dk", "phone": "+4589893300", "city": "Silkeborg" } } </code></pre> Accept-Version: 3</code></strong> — pin’er til API v3.</li> Anonym rate-limit</strong> — dokumenteret på siden, rigeligt til almindelig brug.</li> Ingen garantier</strong> — hvis svaret er forkert, indsend en rettelse på GitHub-repoet. Til kommercielle garantier: se iinlist.com.</li> </ul> Ofte stillede spørgsmål</h2> Er BIN-/IIN-data reguleret?</h3> BIN-ranges i sig selv er ikke persondata under GDPR — en BIN identificerer en udsteder, ikke en person. Kombination af en BIN med et fuldt kortnummer er en anden historie og falder under PCI-DSS.</p> Hvad ændrede sig med 8-cifret IIN-migrationen?</h3> ISO/IEC 7812 formaliserede 8-cifrede IIN’er i 2017 med en hård migrations-deadline i april 2022 for de store netværk. Hvis din kode stadig behandler kun de første seks cifre som udsteder-identifikatoren, fejlrouter du lydløst en voksende del af din trafik — moderne Visa- og Mastercard-udsteder-ranges er defineret ved 8 cifre.</p> Hvorfor ikke bare slå op på klient-siden?</h3> Det kan du, med en statisk liste i browseren. Men du accepterer et trade-off: friskhed (den statiske liste er forældet inden for uger) eller bundle-størrelse (den nuværende BIN-tabel er megabytes ukomprimeret). En server-side-API er det konventionelle svar.</p> Logger binlist.net de BIN’er, jeg slår op?</h3> Kun aggregeret analytics — nok til at opdage misbrug og rate-limite. Enkelte opslag er ikke knyttet til en bruger. iinlist.com har en strammere no-logging-holdning til kunder, hvor det betyder noget.</p> Er kildekoden open source?</h3> API-overfladen af binlist.net er på GitHub med retningslinjer for data-rettelser. Data-ingestion-pipelinen er ikke open source; den afhænger af netværks-feeds, der kræver licenser.</p> Er binlist.net og iinlist.com samme firma?</h3> Adskilte projekter, overlappende oprindelse, samme operatør på min side. binlist.net er en personlig gratis-tjeneste; iinlist.com er et kommercielt selskab med medstiftere og medarbejdere. De to er driftsmæssigt uafhængige, men deler institutionel viden om BIN-data, som ikke er nem at akkumulere fra bunden.</p> Tretten år inde</h2> Det, jeg finder mest interessant ved binlist.net, er ikke trafikken — det er den slags spørgsmål</strong>, udviklere stadig skriver ind i Google i 2026: “what is a bin list”, “bin number example”, “list of issuer identification numbers”. Det er nøjagtig de queries, jeg skrev i 2013 på balkonen i Playitas. Payments som industri fortsætter med at tilføje lag, men de grundlæggende spørgsmål ændrer sig ikke.</p> Hvis du sidder på en strand med en laptop, og du har en kløe til et sideprojekt, der klør din egen ryg: byg det — og prøv imens det sprog, du har haft lyst til at lære. Nogle gange viser det sig, at mange har samme kløe, og tretten år senere har du en nyttig ting at pege dem på og et arbejdende kendskab til Go.</p> Mit CM3588-projekt — 4-NVMe ARM64 hjemme-NAS på 10 W tomgang 2026-04-22T00:00:00+00:00 TL;DR —</strong> FriendlyElec CM3588 NAS Kit</a> er et RK3588-baseret compute-modul på en carrier-board med fire M.2 NVMe-pladser (PCIe 3.0 x1 hver)</strong>, 2,5 GbE</strong>, 2× HDMI ud</strong>, USB 3.0</strong> og en 8-kernet ARMv8-CPU (4× Cortex-A76 + 4× Cortex-A55). Fuldt lastet med fire NVMe-drev går den i tomgang på ca. 10 W</strong>, peaker omkring 20 W under tung I/O, og læser/skriver en NVMe på ca. 1 GB/s (bus-grænsen, ikke drevet). Min egen kører Debian på mainline-kernel, med ZFS på root, fire 2 TB NVMe-drev i en raidz2</code>-pool, Samba til LAN-shares og Tailscale til adgang uden for LAN. Den har erstattet en tower-PC med TrueNAS og skåret NAS-strømforbruget med ca. 60 W.</p> Hvorfor netop dette board</h2> Jeg havde kørt en tower-PC som hjemme-NAS i årevis: en brugt desktop, seks 3,5“-harddiske og en støjende blæser. Det virkede, men den trak 70–80 W tomgang og stod i et skab, der skulle have aktiv udluftning. Harddiskene var højlydte nok til, at jeg havde flyttet dem til det fjerneste hjørne af huset.</p> Tre ting, jeg ville have af en afløser:</p> Kun NVMe.</strong> Roterende harddiske er billigere pr. terabyte, men støjen, vibrationen og varmen er ikke værd for et hjemme-NAS på nogle få terabyte. 4× 2 TB NVMe er rigeligt.</li> ARM, for strømforbrugets skyld.</strong> Et x86-board med 4× PCIe-pladser forbundet til NVMe ville trække 30–40 W tomgang. ARM kan klare det på 10.</li> Mainline Linux, ikke en leverandør-fork.</strong> Jeg vil have apt-get dist-upgrade</code> til at virke, zfs</code> til at bygge fra DKMS mod en nyere kernel og ingen tre år gammel vendor-BSP.</li> </ol> CM3588 NAS Kit rammer alle tre.</p> Hardware</h2> SoC:</strong> Rockchip RK3588 (4× Cortex-A76 @ 2,4 GHz + 4× Cortex-A55 @ 1,8 GHz, Mali-G610 GPU, 6 TOPS NPU). ARMv8.2-A.</li> RAM:</strong> 8 GB LPDDR4X på det modul, jeg købte. 16 GB- og 32 GB-varianter findes.</li> Lagring:</strong> 64 GB eMMC on-module til OS + 4× M.2 Key-M 2280-pladser, hver PCIe Gen 3 x1</strong> (altså ~1 GB/s pr. plads, ikke x4).</li> Netværk:</strong> 1× 2,5 GbE (Realtek RTL8125B).</li> USB:</strong> 2× USB 3.0 Type-A, 1× USB 3.0 Type-C (DisplayPort alt-mode), 1× USB 2.0.</li> Video:</strong> 2× HDMI ud, 1× HDMI ind</strong> (RK3588’s capture-blok).</li> Strøm:</strong> 12 V barrel-jack. Et 60 W-strømforsyning er mere end nok.</li> </ul> Boardet er lille — ca. 10 × 10 cm — og passivt over SoC’en plus en lille blæser, der blæser hen over NVMe-drevene. Mit står fladt på en hylde uden kabinet.</p> NVMe-kompatibilitetsadvarsel</h3> Den ene ting, der er værd at vide: CM3588 NAS Kit er ikke kompatibelt med visse WD Blue SN580- og WD Black SN850-drev</strong> — linket flapper ved boot. Jeg bruger Samsung 990 EVO og Crucial P3 Plus; begge virker fint. Tjek FriendlyElecs wiki-kompatibilitetsliste før du køber NVMe-drev.</p> OS og filsystem</h2> Jeg kører Debian 13 (trixie)</strong> med mainline-kernel</strong> — RK3588-understøttelse er god nok fra 6.8 og frem til headless-brug. FriendlyElecs Debian-image virker ud af boksen, men jeg geninstallerer ovenpå for at få et rent Debian i stedet for deres BSP.</p> Root-filsystem:</strong> ext4</code> på eMMC.</li> Datapool:</strong> zfs</code> raidz2</code> på tværs af de fire NVMe-drev. Med 4× 2 TB giver raidz2</code> ~3,5 TB brugbart med to-disks-redundans. Ja, raidz2</code> på fire drev er konservativt; det betyder også, at et dobbelt-svigt ikke spiser poolen, og på NVMe er rebuilden hurtig nok til, at jeg ikke mister nattesøvn over det.</li> ZFS-modul:</strong> DKMS mod den kørende kernel. Bygger automatisk ved kernel-opgraderinger. Har virket uden manuel indgriben på tværs af tre kernel-bumps.</li> ARC-tuning:</strong> Loftet ved 2 GB. Det giver headroom på et 8 GB-system.</li> </ul> Gennemløbet er flaskehals-begrænset af 2,5 GbE til netværks-I/O (~280 MB/s vedholdende), længe før ZFS eller NVMe-drevene kommer på arbejde. Lokale operationer på poolen når omkring 2 GB/s samlet sekventiel læsning.</p> Tjenester</h2> Bevidst holdt simpelt:</p> Samba</strong> til SMB-shares til Mac’erne og Windows-boksen på LAN’et.</li> rsync + cron</strong> til natlige backups fra tre andre maskiner.</li> ZFS-snapshots</strong> hver time, opbevares en uge. zfs send</code> piper datasættet ugentligt til en offsite B2-bucket via zfs-autobackup</code> + rclone.</li> Tailscale</strong> til adgang uden for LAN. Ingen port-forwarding, ingen dyndns, ingen VPN-koncentrator. SSH og Samba rider begge på Tailscale-interfacet, når jeg er væk.</li> Cockpit</strong> til det lejlighedsvise “hvorfor larmer blæseren” dashboard-øjeblik.</li> </ul> Det er alt. Ingen Docker swarm, ingen Kubernetes, ingen dusin sidecar-containere. Boardet har ét job — serve filer på LAN’et og lade mig trække backups offsite — og det gør det i stilhed.</p> Strøm og støj</h2> Tomgang</strong> (alle fire NVMe opspundne, ingen trafik): ~10 W</strong> ved stikkontakten.</li> Travlt</strong> (NVMe-læsning mætter 2,5 GbE, ZFS-ARC varm): ~18–20 W</strong>.</li> Peak</strong> (scrub af hele poolen, alle kerner varme): ~25 W</strong>.</li> </ul> Sammenlignet med den 70–80 W-tower, den afløste, er strøm-ROI’en alene omkring 500 kWh/år</strong>, eller cirka 1.500 kr/år</strong> ved danske privat-takster. Boardet betalte sig selv tilbage på ca. et år.</p> Støj: i praksis uhørlig fra mere end en meters afstand. Blæseren er lille, og 80 % af tiden kører den knap nok.</p> Hvad virkede ikke, eller tog arbejde</h2> Vendor-kernel.</strong> FriendlyElecs leverede kernel er deres fork af 6.1 med RK-specifikke patches. Det virker til deres nøglefærdige NAS-image, men DKMS-ZFS-builds er bøvlede mod den. Skiftet til mainline løste det.</li> HDMI-capture.</strong> RK3588 har en hardware HDMI-input-blok. I mainline er den stadig eksperimentel. Jeg har en vag brugscase for den (trække signal fra en gammel enhed til arkivering), men har ikke fået det til at virke end-to-end. Parkeret indtil videre.</li> NPU.</strong> De 6 TOPS NPU er underudnyttet. Mainline har basal RKNPU-understøttelse, men til noget praktisk skal du stadig bruge FriendlyElecs rknn-toolkit2</code>. Ikke et problem for et NAS.</li> </ul> Ofte stillede spørgsmål</h2> Hvorfor ikke x86?</h3> En x86-mini-PC med 4× NVMe er ~2× tomgangsstrømmen og ~2× købsprisen (når du tæller kabinet, PSU og CPU med). Til et hjemme-NAS, hvor arbejdsbyrden er “serve filer” snarere end “kør 40 containere”, vinder ARM.</p> Hvorfor ikke Raspberry Pi 5?</h3> Pi 5 har én PCIe 2.0 x1-lane eksponeret via en HAT — du kan bolte en NVMe på, men kun én, med loft ved ~500 MB/s. CM3588 har fire lanes ved PCIe 3.0 direkte forbundet. En anden klasse af board.</p> Hvorfor ikke OpenMediaVault eller TrueNAS?</h3> Begge ville virke. Jeg foretrækker rent Debian + Samba + ZFS, fordi opgraderingsstien for Debian er velkendt for mig, og OMV/TrueNAS er et lag, jeg skulle lære på ny. Det afhænger af dig.</p> Hvorfor raidz2</code> på fire drev og ikke mirror + mirror</code>?</h3> Overvejet. mirror + mirror</code> giver hurtigere skriv og lettere udvidelse, men kun 4 TB brugbart fra 4× 2 TB — det samme som raidz2</code>. Med raidz2</code> kan to vilkårlige drev svigte; med stripede mirrors kan du miste to drev, men kun hvis de er i forskellige mirror-par. På fire drev er kapaciteten identisk, og raidz2</code> har den stærkere fejltolerance.</p> Kan den køre Plex / Jellyfin?</h3> Ja, og RK3588’s hardware H.265/VP9/AV1-decode-blok klarer det tunge arbejde. Jellyfin med rkmpp</code>-accelereret decoding håndterer 4K HEVC-transcodes på omkring 3× realtid. Jeg kører ingen af delene på denne boks — min Plex bor et andet sted — men det er realistisk.</p> Går den i suspend?</h3> Ikke pålideligt. Lad den stå tændt; tomgang er alligevel 10 W.</p> Hvad med støj og varme om sommeren?</h3> Passivt køleplade plus en lille blæser. I en dansk sommer (20–25 °C i rummet) topper den omkring 55 °C die-temperatur under en ZFS-scrub. Ingen throttling målt.</p> Dom</h2> Hvis du vil have et lydsvagt, strømbesparende, ren-NVMe-hjemme-NAS med nok PCIe til at betyde noget</strong> og er villig til at bruge en aften på Debian + ZFS, er CM3588 NAS Kit den bedste mulighed, jeg har fundet. Det er ikke det billigste — en brugt Optiplex er billigere på forhånd — men på tre års TCO inkl. strøm betaler det sig tydeligt tilbage.</p> RK3588 i sig selv er en overraskende kapabel SoC til homelab-arbejdsbyrder. Da mainline-kernel-understøttelsen landede, holdt jeg op med at behandle den som “en ARM-kuriositet” og begyndte at behandle den som default-svar på små altid-tændte servere.</p> To år inde er min blevet genstartet to gange (en gang for en kernel-opgradering, en gang fordi jeg flyttede hylden). Jeg ville købe den igen.</p> pdfcrack — gendan glemte PDF-kodeord på Linux og macOS (2026) 2026-04-22T00:00:00+00:00 TL;DR —</strong> pdfcrack</code></strong> er et kommandolinjeværktøj, der gendanner user-kodeordet</strong> eller owner-kodeordet</strong> på en krypteret PDF via brute-force eller dictionary-angreb. Det er lille, skrevet i C, kører på Linux/macOS/WSL og håndterer enhver krypterings-profil, PDF har leveret — 40-bit RC4, 128-bit RC4, 128-bit AES, 256-bit AES (PDF 1.7 + 2.0). Det er single-threaded og kun CPU</strong>, så det er hurtigt på den svage gamle RC4-40-kryptering, men stadig langsommere, efterhånden som PDF’er bliver moderne. Installeres med apt install pdfcrack</code> (Debian/Ubuntu), brew install pdfcrack</code> (macOS) eller bygges fra kilden. Når pdfcrack</code> er for langsom, så skift til pdf2john</code> + hashcat</code></strong> på en GPU.</p> Dette indlæg antager, at du har autorisation til at gendanne kodeordet</strong> på PDF’en — dit eget dokument, en kundes eller en lovligt anskaffet fil. Angrib ikke PDF’er, du ikke ejer.</p> User-kodeord vs owner-kodeord</h2> PDF har to kodeord:</p> User-kodeord</strong> — kræves for at åbne og læse</strong> dokumentet.</li> Owner-kodeord</strong> — kræves for at fjerne begrænsninger</strong> (print, kopi, rediger) på et dokument, der åbner uden et user-kodeord.</li> </ul> Mange “beskyttede” PDF’er er kun owner-kodeord-begrænsede: de åbner fint, men print og kopi er deaktiveret af læseren. Dem er trivielt at låse op — qpdf --decrypt</code> eller et hvilket som helst pdftk</code>-lignende værktøj fjerner owner-only-restriktioner uden at skulle gætte noget. pdfcrack</code> er til det sværere tilfælde: en user-kodeord-beskyttet PDF, du slet ikke kan åbne</strong>.</p> Tjek hvilken du har med at gøre:</p> $ qpdf --show-encryption dokument.pdf R = 6 P = -3904 User password = Supplied password is owner password extract for accessibility: allowed extract for any purpose: not allowed print low resolution: allowed print high resolution: not allowed modify document assembly: not allowed modify forms: not allowed modify annotations: not allowed modify other: not allowed stream encryption method: AESv3 string encryption method: AESv3 file encryption method: AESv3 </code></pre> R = ...</code></strong> fortæller dig revisionen/profilen. R=2</code> = RC4-40, R=3</code> = RC4-128, R=4</code> = AES-128, R=5/6</code> = AES-256.</li> “Supplied password is owner password”</strong> + “User password = (tom)” betyder, du kan åbne den og bare skal fjerne restriktioner. Brug qpdf --decrypt --password='' input.pdf output.pdf</code>, og du er færdig.</li> </ul> Installation</h2> # Debian / Ubuntu / Mint / Kali sudo apt install pdfcrack # macOS (Homebrew) brew install pdfcrack # Arch / Manjaro sudo pacman -S pdfcrack # Fedora / RHEL sudo dnf install pdfcrack # Fra kilden wget https://sourceforge.net/projects/pdfcrack/files/latest/download -O pdfcrack.tar.gz tar xf pdfcrack.tar.gz && cd pdfcrack- make sudo cp pdfcrack /usr/local/bin/ </code></pre> Benchmark</h2> $ pdfcrack -b Benchmark: Average Speed (calls / second): MD5: 1728972.6 MD5_50 (fast): 97879.3 MD5_50 (slow): 69167.0 RC4 (40, static): 606555.3 RC4 (40, no check): 598050.0 RC4 (128, no check): 590141.7 Benchmark: Average Speed (passwords / second): PDF (40, user): 453510.2 PDF (40, owner): 220250.0 PDF (40, owner, fast): 499995.0 PDF (128, user): 22000.0 PDF (128, owner): 10408.7 PDF (128, owner, fast): 22220.0 </code></pre> Oversat:</p> RC4-40</strong> (PDF 1.3, meget gammel) — ~450k kodeord/sek. Brute-force af et fuldt 8-tegns alfanumerisk space: ~1 uge på én core.</li> RC4-128 / AES-128</strong> — ~22k kodeord/sek. Brute-force bliver urealistisk over længde 6 med et hvilket som helst charset.</li> AES-256 (R=5/6)</strong> — endnu langsommere; pdfcrack</code> understøtter det, men reelt kun til dictionary-angreb mod små ordlister.</li> </ul> Har du brug for mere fart end det, så vil du bruge hashcat</code> på en GPU. Tal i bunden.</p> Dictionary-angreb</h2> pdfcrack -f dokument.pdf -w /usr/share/wordlists/rockyou.txt </code></pre> -f</code></strong> — målfil.</li> -w <fil></code></strong> — ordliste, én kandidat pr. linje.</li> Valgfri -o</code></strong> — angrib kun owner-kodeord (ignorer user-kodeord). Default er at prøve user-kodeord først.</li> Valgfri -u</code></strong> — angrib kun user-kodeord.</li> </ul> Har du kontekst — kodeordet er sandsynligvis et fornavn, et årstal, en projektkode — saml en mindre målrettet liste. Generiske lister er en lang skud, når du er forbi top ti tusind indgange.</p> Brute-force-angreb</h2> pdfcrack -f dokument.pdf -c 'abcdefghijklmnopqrstuvwxyz0123456789' -n 4 -m 8 </code></pre> -c <charset></code></strong> — tegnsæt at prøve. Default inkluderer et bredt ASCII-område.</li> -n <min></code></strong> — minimumslængde.</li> -m <max></code></strong> — maksimumslængde.</li> </ul> Juster -c</code> aggressivt. Ved du, at kodeordet er alt-lowercase, så giv det ikke uppercase. Ved du, det har et ciffer til sidst, så brug et mask-angreb (hashcat-territorium, ikke pdfcrack).</p> Genoptag et langt kørsel</h2> pdfcrack -f dokument.pdf -w rockyou.txt -s /tmp/state.sav </code></pre> -s</code> skriver periodiske save-filer; hvis du stopper pdfcrack og genstarter, så giv -l /tmp/state.sav</code> for at genoptage.</p> Hvornår du skal skifte til hashcat</h2> Til enhver moderne PDF (R=4, 5 eller 6 — altså AES-128 eller AES-256) bliver pdfcrack</code>s single-core-fart flaskehalsen. pdf2john</code> + hashcat</code> giver dig to til tre størrelsesordener mere throughput på en GPU.</p> Trin 1: træk hashen ud</h3> $ /usr/share/john/pdf2john.pl dokument.pdf > hash.txt </code></pre> (På Debian/Ubuntu: apt install john</code> leverer pdf2john.pl</code>.)</p> Trin 2: identificér hash-mode</h3> $ head -1 hash.txt dokument.pdf:$pdf$56256-1028116... </code></pre> Map de første to tal:</p> $pdf$12...</code> → mode 10400</strong> (PDF 1.1–1.3, RC4-40, user)</li> $pdf$12...</code> med owner-salt → mode 10410 / 10420</strong></li> $pdf$23...</code> → mode 10500</strong> (PDF 1.4–1.6, RC4-128 / AES-128)</li> $pdf$55...</code> → mode 10600</strong> (PDF 1.7 r=5, AES-256)</li> $pdf$56...</code> → mode 10700</strong> (PDF 1.7 r=6 / PDF 2.0, AES-256 med PBKDF2)</li> </ul> Trin 3: kør hashcat</h3> hashcat -m 10700 hash.txt /sti/til/ordliste.txt </code></pre> På en enkelt moderne GPU (fx RTX 4090):</p> Mode 10400 (RC4-40):</strong> ~10 milliarder H/s — ethvert praktisk kodeord gendannes øjeblikkeligt.</li> Mode 10500 (RC4-128 / AES-128):</strong> ~100 millioner H/s.</li> Mode 10700 (AES-256, PBKDF2):</strong> ~50.000 H/s. Det er ved design — PBKDF2-iterationerne gør brute-force dyrt.</li> </ul> For mode 10700 betyder din angrebsstrategi mere end rå fart. Dictionary + regler + mask-angreb målrettet mod sandsynlige kodeord-mønstre er størrelsesordener mere produktive end udtømmende brute-force.</p> Almindelige faldgruber</h2> “Filen ser ud til at være krypteret, men jeg kan åbne den uden kodeord”</h3> Du ser på owner-only-restriktioner. Brug qpdf --decrypt input.pdf output.pdf</code> — ingen cracking nødvendigt.</p> pdfcrack kører, men finder aldrig noget</h3> Tre sandsynlige årsager:</p> Kodeordet er længere / mere komplekst, end dit charset × længde dækker.</strong> Øg -m</code> og/eller udvid -c</code>, eller skift til en dictionary.</li> Kodeordet indeholder ikke-ASCII-tegn.</strong> pdfcracks charset er ASCII som default; ikke-ASCII-user-kodeord i gamle PDF’er brugte varierende encodings (PDFDocEncoding, UTF-16). Prøv pdf2john</code> + hashcat, som håndterer encoding’en korrekt.</li> Det er AES-256 (R=6), og du er tålmodig.</strong> Se hastighedsnoterne ovenfor — kun realistisk med en dictionary.</li> </ol> “Only AES-256 is supported”-fejl eller lignende</h3> Din pdfcrack</code>-build er gammel. Ubuntu LTS leverer nogle gange en version, der ikke fuldt håndterer R=6. Byg fra kilden eller skift til pdf2john</code> + hashcat</code>.</p> PDF’en åbner, men print/kopi er blokeret</h3> Det er kun owner-kodeord-begrænset. qpdf --decrypt</code> uden at behøve et kodeord virker som regel:</p> qpdf --decrypt --password='' input.pdf output.pdf </code></pre> Defensiv pointe</h2> Til alt, du vil have til at forblive krypteret i 2026, brug AES-256 med en PDF 2.0 (R=6) kodeord</strong>. Det er profilen med PBKDF2-nøgle-afledning, der gør offline-angreb dyre på nuværende hardware.</p> Og som altid betyder kodeordets længde mere end noget andet. En 20-tegns tilfældig passphrase er brute-force-intraktabel mod enhver nuværende GPU. Et 6-tegns “smart substitutions”-kodeord er en kaffepause på en RTX 4090.</p> Ofte stillede spørgsmål</h2> Er pdfcrack stadig vedligeholdt?</h3> Opdateres langsomt. Kodebasen håndterer alle nuværende PDF-krypterings-profiler; det er bare ikke her, performance-arbejdet foregår længere (det er hashcat).</p> Bruger pdfcrack GPU?</h3> Nej. Kun CPU, single-threaded. Til GPU-arbejde, brug pdf2john</code> + hashcat</code>.</p> Kan pdfcrack gendanne dokumentet, hvis skaberen ryddede user-kodeordet, men beholdt owner-kodeordet?</h3> Ja — brug qpdf --decrypt</code> først; hvis det ikke fuldt dekrypterer, angriber pdfcrack -o</code> owner-kodeordet.</p> Lækker pdfcrack min PDF nogle steder?</h3> Nej. Den er lokal. Alt online-only (“crack min PDF på cloud-service-X.com”) indebærer at uploade filen, hvilket du ikke skal gøre for fortroligt materiale.</p> Hvad hvis jeg kun vagt husker kodeordet?</h3> Skriv ned, hvad du husker — sandsynlige ord, sandsynlige cifre, sandsynlig længde — og byg en målrettet ordliste eller et hashcat</code>-mask (-a 3 ?l?l?l?l?l?d?d?d?d</code>). Det slår enhver generisk liste.</p> Kan jeg gendanne tekst fra en AES-256-PDF uden kodeordet?</h3> Nej. AES-256 med PBKDF2 (R=6) er, så vidt offentlig kryptanalyse går, ikke brudt. Hvis kodeordet er stærkt og tabt, er indholdet tabt.</p> Opsummering</h2> Kun owner-kodeord?</strong> qpdf --decrypt</code>, ingen cracking nødvendigt.</li> User-kodeord-beskyttet, gammel (R=2/3)?</strong> pdfcrack</code> med en dictionary virker fint.</li> Moderne (R=4/5/6)?</strong> pdf2john</code> + hashcat</code> på en GPU, målrettet angreb.</li> Stærk 20-tegns tilfældig?</strong> Accepter tabet.</li> </ul> fcrackzip — gendan glemte zip-kodeord på Linux, macOS og Windows (2026) 2026-04-22T00:00:00+00:00 TL;DR —</strong> fcrackzip</code></strong> er et gratis, open-source kommandolinjeværktøj til at gendanne kodeordet på en krypteret .zip</code>-fil. Det understøtter brute-force</strong> (over et bruger-defineret charset og længde) og dictionary</strong>-angreb, virker på Linux/macOS/WSL, og er det rigtige første værktøj, når du skal gendanne et glemt kodeord på en zip, du lovligt ejer. Det er kun hurtigt mod klassisk ZipCrypto</strong>-kryptering; til den nyere AES-256</strong>-zip-profil virker fcrackzip</code> ikke — så skal du bruge zip2john</code> + hashcat</code> i stedet. Installeres med apt install fcrackzip</code> (Debian/Ubuntu), brew install fcrackzip</code> (macOS) eller bygges fra kilden.</p> Dette indlæg går gennem de praktiske tilfælde. Det antager, at du har autorisation til at gendanne kodeordet</strong> — dine egne filer, en kundes, en CTF. Brug det ikke på zips, du ikke ejer.</p> Installation</h2> # Debian / Ubuntu / Mint / Kali sudo apt install fcrackzip # macOS (Homebrew) brew install fcrackzip # Arch / Manjaro sudo pacman -S fcrackzip # Windows # Brug WSL2 + Ubuntu og `apt install fcrackzip`. # En native .exe findes, men er gammel — WSL er simplere. # Fra kilden git clone https://github.com/hyc/fcrackzip.git cd fcrackzip && ./configure && make sudo cp fcrackzip /usr/local/bin/ </code></pre> Tjek først, hvilken kryptering din zip bruger</h2> fcrackzip</code> håndterer kun klassisk ZipCrypto</strong> (den originale, svage PKZIP-kryptering). Til moderne AES-128 / AES-256</strong>-zips (introduceret af WinZip 9 i 2003, nu default i nogle værktøjer) vil fcrackzip</code> lydløst fejle i at finde kodeordet, uanset hvor længe du lader det køre.</p> Hurtigste tjek med zipinfo</code>:</p> $ zipinfo -v arkiv.zip \| head -40 </code></pre> Led efter WinZip AES encryption, strength 3</code> (= AES-256). Ser du det, så spring til hashcat-sektionen.</p> Eller med 7z</code>:</p> $ 7z l -slt arkiv.zip \| grep -i 'method\\|encrypted' Method = ZipCrypto Store ← fcrackzip virker Method = AES-256 Deflate ← fcrackzip virker IKKE </code></pre> Grundlæggende brute-force</h2> fcrackzip -v -b -c 'a1' -p aaaa -u arkiv.zip </code></pre> -v</code></strong> — verbose.</li> -b</code></strong> — brute-force-mode.</li> -c 'a1'</code></strong> — charset. a</code> = små bogstaver a–z</code>, A</code> = store, 1</code> = cifre, !</code> = printbare symboler. Kombiner: 'aA1!'</code> = alt printbart ASCII (94 tegn).</li> -p aaaa</code></strong> — start-kodeord (definerer minimum-længde = 4 her).</li> -u</code></strong> — rapporterer kun, hvis den dekrypterede fil “unzipper” rent (filtrerer falske positive — ZipCrypto har en lille CRC, som mange tilfældige kodeord passerer).</li> </ul> Længde: -p aaaaa</code> starter ved 5 tegn. fcrackzip</code> har ikke et --max-length</code>-flag; det inkrementerer start-kodeordet gennem charsettet uendeligt, så at lade det køre til “færdigt” ved længde 8 på det fulde printbare ASCII-charset er ca. 94⁸ ≈ 6×10¹⁵ kandidater</strong> — ikke realistisk. Du afgrænser angrebet ved at vælge et rimeligt max charset + længde eller ved at bruge en dictionary.</p> Dictionary-angreb</h2> fcrackzip -v -D -u -p /usr/share/wordlists/rockyou.txt arkiv.zip </code></pre> -D</code></strong> — dictionary-mode.</li> -p <fil></code></strong> — ordliste-fil, én kandidat pr. linje.</li> -u</code></strong> — verificér via unzip, som før.</li> </ul> rockyou.txt</code> er den standard 14 M-indgange-ordliste, der leveres med Kali og er tilgængelig overalt. Har du kontekst om kodeordet (det er nogens navn + årstal, det er et projektkodenavn), så saml en mindre målrettet ordliste — hit-raterne er som regel meget højere end med en generisk liste.</p> Hastighed og hvad du kan forvente</h2> fcrackzip</code> er single-threaded og CPU-bundet. På en moderne laptop ser du groft:</p> 10–30 millioner ZipCrypto-forsøg pr. sekund pr. core</strong> for et dictionary-angreb mod en typisk zip.</li> Brute-force en anelse hurtigere pga. mindre streng-I/O.</li> </ul> Det gør den fin til:</p> Dictionary-angreb</strong> mod en hvilken som helst rimelig ordliste.</li> Kort brute-force</strong> (4–6 tegn alfanumerisk).</li> </ul> Det gør den uegnet til:</p> Længde 8+ med symboler</strong> — du når aldrig i mål.</li> AES-256-zips</strong> — forkert værktøj.</li> </ul> Hvornår du skal skifte til hashcat</h2> Hvis fcrackzip</code> er for langsom, eller zip’en er AES-krypteret, så gå over til hashcat</code>. Det er det general-purpose kodeord-cracking-værktøj, GPU-accelereret, og håndterer både ZipCrypto og AES-WinZip-hashes.</p> Trin 1: træk hashen ud med zip2john</code></h3> zip2john</code> er en del af John the Ripper. Ubuntu: apt install john</code>.</p> $ zip2john arkiv.zip > hash.txt $ cat hash.txt arkiv.zip:$zip2$030...$/zip2$::arkiv.zip:hemmelig.pdf:/sti/til/arkiv.zip </code></pre> Trin 2: fodr den til hashcat</h3> # ZipCrypto (mode 17200, 17210, 17220, 17225 afhængigt af komprimering) hashcat -m 17200 hash.txt /sti/til/ordliste.txt # AES-krypteret WinZip (mode 13600) hashcat -m 13600 hash.txt /sti/til/ordliste.txt </code></pre> På en enkelt moderne diskret GPU (fx RTX 4090) ser du:</p> ZipCrypto: ~5–10 milliarder H/s</strong></li> WinZip AES-256: ~10–50 millioner H/s</strong> (meget langsommere, fordi AES er dyrt, og der er PBKDF2-iterationer involveret)</li> </ul> hashcats rule-engine, mask-angreb (-a 3</code>) og combinator-mode (-a 1</code>) gør den massivt mere fleksibel end fcrackzip</code>. Til alt ikke-trivielt er den det rigtige værktøj.</p> Almindelige faldgruber</h2> “PASSWORD FOUND!!!!: pw == abc”, men unzip</code> beder stadig om et kodeord</h3> Du brugte ikke -u</code>. fcrackzips CRC-tjek har falske positive. Kør igen med -u</code> for at verificere kandidater mod et rigtigt dekomprimerings-forsøg.</p> Forskellige filer i samme zip har forskellige kodeord</h3> Klassisk PKZIP understøtter per-fil-kodeord. fcrackzip</code> angriber én fil ad gangen; giv -l <filnavn></code> (eller lad den vælge den første krypterede) hvis du skal være specifik.</p> fcrackzip finder kodeordet, men jeg kan stadig ikke unzippe</h3> Charset/locale-problem. Hvis kodeordet indeholder ikke-ASCII-tegn, har zip’ens skaber måske brugt en anden encoding end din terminal. Prøv unzip -P "$(echo -n 'passwd' \| iconv -t cp437)" arkiv.zip</code>.</p> AES-krypteret, og dictionary finder det ikke</h3> hashcat + regler + en målrettet ordliste er løsningen. Se migrations-trinnene ovenfor.</p> Defensiv pointe</h2> Hvis du laver zip-filer, der skal forblive krypterede: brug AES-256</strong>, ikke ZipCrypto. De fleste moderne værktøjer (7z</code>, zip</code> fra InfoZIP med -e</code>, WinZip, Keka) giver dig AES, hvis du beder om det. Default på zip</code> er desværre stadig ZipCrypto på mange systemer. Tjek med 7z l -slt arkiv.zip</code> før du sender den afsted.</p> Og vælg et kodeord med længde, ikke smarthed. hashcat</code> er ligeglad med, hvor mærkeligt dit substitutions-mønster er; det handler kun om entropi. En fire-ords passphrase (correct-horse-battery-staple</code>-stil, ~44 bit) er fin mod offline ZipCrypto-angreb; et tilfældigt 12-tegns blandet kodeord (~78 bit) er fint mod GPU-AES-angreb. Alt kortere er genvindbart.</p> Ofte stillede spørgsmål</h2> Er fcrackzip lovligt?</h3> At gendanne kodeord på filer du ejer eller har autorisation til at tilgå, er lovligt i alle jurisdiktioner, jeg kender. At gøre det på en andens fil uden autorisation er uautoriseret adgang — samme lov som for enhver anden computer-indtrængen.</p> Er fcrackzip vedligeholdt?</h3> Kun lige. Kodebasen har været stabil i femten-plus år. Til moderne arbejde har kombinationen af zip2john</code> + hashcat</code> overtaget.</p> Kan fcrackzip bruge en GPU?</h3> Nej. fcrackzip</code> er kun CPU. Hvis GPU er det, du har, så gå direkte til hashcat.</p> Håndterer fcrackzip .7z, .rar, .gpg-filer?</h3> Nej — kun klassisk PKZIP .zip</code>. Til .7z</code>, brug 7z2john</code> + hashcat (mode 11600). Til .rar</code>, rar2john</code> + hashcat (mode 12500 / 13000). Til .gpg</code>, gpg2john</code> + hashcat (mode 17010+).</p> Hvordan genererer jeg en målrettet ordliste?</h3> hashcat</code>s maskprocessor (mp64</code>), crunch</code> og cewl</code> (crawler et site for kandidat-ord) er alle værd at kende. Til at gendanne et specifikt glemt kodeord er den højeste-yield-tilgang at skrive ned, hvad du husker om det — længde, sandsynlige ord, sandsynlige tal — og bygge et mask-angreb fra det.</p> Opsummering</h2> fcrackzip</code> + -D</code> + en ordliste er det rigtige første forsøg.</li> Virker det ikke, og det er ZipCrypto: fcrackzip</code> + -b</code> med et snævert charset og kort længde.</li> Virker det ikke, eller det er AES: zip2john</code> + hashcat</code> på en GPU.</li> Virker det ikke: dit kodeord var stærkt nok. Det er systemet, der virker som tiltænkt.</li> </ul> Wi-Fi-hacking gennem 25 år — 2002, 2007, 2012, 2017, 2022, 2027 2026-04-22T00:00:00+00:00 TL;DR —</strong> Wi-Fi-sikkerhed har været gennem fire generationer — WEP</strong>, WPA</strong>, WPA2</strong>, WPA3</strong> — hver introduceret, fordi forgængeren var brudt. Dette indlæg går gennem seks snapshots af state of the art: 2002</strong> (WEP, trivielt), 2007</strong> (WEP død, WPA udbredt, offline-angreb kommer frem), 2012</strong> (WPA2 dominerer, dictionary-angreb på GPU’er), 2017</strong> (KRACK bryder WPA2 under de rette betingelser, PMKID-lækken i 2018), 2022</strong> (WPA3 ruller ud, downgrade-angreb, cloud-skala-cracking), 2027</strong> (dagens landskab: WPA3 næsten universel, 6 GHz åbner ny overflade, angreb flytter op i stakken). For hvert år opsummerer jeg angrebet, værktøjet og hvad en forsvarer burde have gjort. Kun autoriseret testning — den defensive vejledning i bunden er pointen.</p> Overblik</h2> År</th> Dominerende standard</th> Hovedangreb</th> Indsats for typisk netværk</th> Hurtigste dictionary / nøgle-rate dengang</th></tr></thead> 2002</td> WEP (100%)</td> FMS statistisk IV</td> ~4M pakker / 2–10 t på aktivt AP</td> N/A — nøglen udledes af IV’er</td></tr> 2007</td> WEP 35%, WPA 25%, WPA2 20%, åben 20%</td> PTW + aircrack-ng</td> 40–85k pakker / <5 min (WEP)</td> ~50–100 PSK/s (CPU, cowpatty)</td></tr> 2012</td> WPA2 ~70%</td> Reaver (WPS) + GPU PSK dictionary</td> 11.000 WPS-PIN-forsøg / 2–10 t</td> ~75.000 PSK/s (GTX 580)</td></tr> 2017</td> WPA2 ~85%</td> KRACK; derefter PMKID (2018)</td> 1 pakke (PMKID) → offline dict</td> ~400.000 PSK/s (GTX 1080)</td></tr> 2022</td> WPA2 ~60%, WPA3 ~20%, mixed ~15%</td> Dragonblood downgrade</td> Tving WPA2-fallback, så GPU/cloud</td> ~1,2M PSK/s (RTX 3090), ~10M (8× A100)</td></tr> 2027</td> WPA3 ~40%, mixed ~35%, WPA2 ~20%</td> Klient-side + downgrade + chipset-FW</td> SAE intakt; legacy WPA2 på lånt tid</td> ~5–8M PSK/s (RTX 5090-klasse enkelt GPU)</td></tr> </tbody></table> Globale udbredelses-andele er omtrentlige, afledt af offentlige Wi-Fi-målinger (WiGLE-trends + leverandør-rapporter); regn med ± 10 procentpoint.</p> 2002 — WEP overalt, og trivielt brudt</h2> Standard:</strong> IEEE 802.11b med WEP</strong> (Wired Equivalent Privacy). 40-bit eller 104-bit RC4-nøgle, 24-bit IV, CRC-32-integritet.</p> Hvad er galt med den:</strong> IV’en er for lille, nøglerne er statiske, og RC4’s initial key schedule lækker bits af nøglen, når visse IV’er bruges. Det er FMS-angrebet</strong> (Fluhrer, Mantin, Shamir, 2001) og dets efterkommere.</p> Hvad en angriber gjorde i 2002:</strong> fangede trafik med en Prism-baseret USB-adapter, indsamlede et par millioner pakker (timer på et aktivt netværk) og udtrak nøglen med AirSnort</strong> eller WEPCrack</strong>. Angrebene var så pinlige, at Wi-Fi Alliance skubbede WPA som en midlertidig firmware-patchbar løsning i 2003.</p> Tal (2002):</strong></p> Global Wi-Fi-udbredelse:</strong> ~100% WEP (WPA blev først ratificeret marts 2003).</li> Nøglelængde:</strong> 40 bit (eksport-grade) eller 104 bit. Irrelevant — angrebet er på IV’en, ikke på nøglen.</li> IV-space:</strong> 24 bit → kun ~16,7 M mulige IV’er. Fødselsdags-kollision efter ~5.000 pakker.</li> FMS-angrebets pakke-antal:</strong> ~500 k–4 M “interessante” IV-frames (få timers aktiv trafik).</li> Typisk crack-tid i ur-tid:</strong> 2–10 t på et travlt SOHO-netværk.</li> Forbrugerhardware:</strong> én laptop + én Prism2/Prism2.5 USB-dongle (~$40 brugt dengang).</li> Værktøjer:</strong> AirSnort, WEPCrack, Kismet til capture.</li> CVE’er:</strong> WEP er ikke i sig selv en CVE, men Borisov/Goldberg/Wagner (2001) og FMS-paperet (2001) er de kanoniske referencer.</li> </ul> Hvad en forsvarer burde have gjort:</strong> erkendt, at WEP ikke er en sikkerhedsfunktion, og behandle det trådløse LAN som ubetroet. Brug en VPN eller IPSec på lag 3.</p> 2007 — WEP død, WPA overgangsvis, WPA2 på vej</h2> Standard:</strong> WPA (2003), en nød-løsning med per-pakke-nøgler (TKIP). WPA2 (2004) med AES-CCMP begynder at dukke op i hjemme-routere.</p> Hvad der er nyt for angribere:</strong> PTW-angrebet</strong> på WEP (2007) reducerer pakke-antallet fra ~1 million til ~40.000 — WEP kan nu crackes på minutter. aircrack-ng</strong> bliver den kanoniske toolkit. Mod WPA-Personal bliver offline-dictionary-angreb på 4-way-handshake praktiske på CPU’er: fang en handshake, fodr PSK-afledningen gennem cowpatty</code> eller aircrack-ng</code>, prøv dictionary-indgange én ad gangen.</p> Hvad angribere endnu ikke havde:</strong> meningsfuld GPU-acceleration af WPA-PSK. Dictionary-angreb var langsomme.</p> Tal (2007):</strong></p> Global udbredelse (WiGLE-målinger):</strong> WEP ~35%, WPA ~25%, WPA2 ~20%, åben ~20%.</li> PTW-angrebets pakke-antal:</strong> ~40.000–85.000 fangede frames for at gendanne en WEP-nøgle (ned fra millioner).</li> Crack-tid med aircrack-ng + pakke-injektion:</strong> <5 minutter, ofte under 60 sekunder.</li> WPA-PSK dictionary-rate (CPU, cowpatty/aircrack-ng):</strong> ~50–100 kandidater/sek pr. core.</li> Rockyou-ordliste</strong> (lækket dec. 2009): 14,3 M indgange — blev de-facto engelsk PSK-ordliste.</li> WPA2 obligatorisk for Wi-Fi CERTIFIED:</strong> marts 2006.</li> Aircrack-ng 1.0:</strong> udgivet 2006, konsoliderede økosystemet.</li> </ul> Hvad en forsvarer burde have gjort:</strong> migrere til WPA2-AES-CCMP, vælg en PSK længere end nogen dictionary. Drop WEP-netværk helt.</p> 2012 — WPA2 dominerer, GPU-cracking moden</h2> Standard:</strong> WPA2 er default på stort set al consumer-gear. WPA2-Enterprise (802.1X / EAP) i corporate-netværk.</p> Hvad der er nyt for angribere:</strong> hashcat</strong> og oclHashcat</strong>, pyrit</strong> og John the Ripper</strong> gør WPA-PSK-dictionary-angrebet til et GPU-problem</strong>. En handshake-capture + en enkelt moderne GPU klarer titusindvis af kandidat-PSK’er pr. sekund; en lille lejet GPU-farm håndterer hundredtusinder. airodump-ng</strong> + Reaver</strong> (2011) udnytter en implementerings-fejl i WPS-PIN</strong> til at gendanne WPA-PSK’en helt uden en dictionary — en dødsdom for hjemme-routere med WPS-on-by-default.</p> Tal (2012):</strong></p> Global udbredelse:</strong> WPA2 ~70%, WEP ~10%, åben ~15%, WPA ~5%.</li> WPS-PIN-space på papir:</strong> 10⁸ = 100 millioner. Effektiv</strong> angrebs-space efter Viehböck-splittet: 10⁴ + 10³ = ~11.000 forsøg.</li> Reaver ur-tid til at gendanne WPS-PIN → PSK:</strong> 2–10 timer mod en upatched AP.</li> hashcat WPA-PSK throughput på GTX 580 (reference-GPU 2012):</strong> ~75.000 kandidater/sek.</li> hashcat WPA-PSK på en lille 4-GPU-rig fra æraen:</strong> ~300.000 kandidater/sek, dvs. rockyou.txt</code> (14,3 M) på ~50 sekunder.</li> Virkelig PSK-gendannelsesrate med rockyou + almindelige regler:</strong> ~20–25% på fangede handshakes i akademiske studier.</li> WPA2-PEAP/MSCHAPv2-hashrate (et Wi-Fi-tilstødende Enterprise-problem):</strong> titusinder af millioner/sek på en enkelt GPU, fuldt 2²⁸-keyspace inden for et døgn.</li> </ul> Hvad forsvarere burde have gjort:</strong></p> Slå WPS fra.</strong> De fleste routere havde den tændt som default.</li> Brug lange tilfældige PSK’er</strong>, ikke dictionary-ord.</li> Til enterprise: 802.1X + EAP-TLS med klient-certifikater</strong>, ikke PEAP-MSCHAPv2 (som i sig selv er et GPU-problem).</li> </ul> 2017 — KRACK</h2> Standard:</strong> WPA2 stadig overalt.</p> Hvad der er nyt for angribere:</strong> KRACK</strong> (Vanhoef, Piessens, 2017) — Key Reinstallation Attack. Det cracker ikke PSK’en. Det udnytter en subtil fejl i 4-way-handshaken, hvor, under visse betingelser (specifikt på Android 6+ og wpa_supplicant 2.4–2.6), genafspilning af handshake-meddelelse 3 får klienten til at geninstallere en all-zero session-nøgle</strong>. Derfra kan angriberen dekryptere udvalgt trafik og, afhængigt af cipher suite, injicere pakker.</p> Hvad gjorde KRACK anderledes end tidligere angreb:</strong> det ramte protokollen, ikke nøglen</strong>. En stærk PSK hjalp ikke. Hver WPA2-implementation havde brug for en patch. De fleste leverandører leverede en inden for uger; nogle tog år.</p> Også i denne æra:</strong></p> PMKID hashcat-angrebet</strong> (2018, Steube). Mange AP’er lækker PMKID’en i en enkelt besked; én pakke er nok til at starte et offline PSK-angreb. Sænkede capture-barren yderligere — ingen klient-association nødvendig.</li> Evil twin / captive portal-phishing.</strong> Efterhånden som enheds-UI’er blev smukkere, blev falske captive portals alarmerende effektive mod mennesker.</li> </ul> Tal (2017–2018):</strong></p> Global udbredelse:</strong> WPA2 ~85%, WEP <3%, åben ~10%, WPA3 endnu ikke leveret.</li> KRACK CVE’er:</strong> 10 i den koordinerede offentliggørelse (CVE-2017-13077 til CVE-2017-13088).</li> KRACK-berørte enheder:</strong> alle WPA2-klienter og AP’er — 10+ milliarder</strong> endpoints. Reel patching tog år for long-tail-IoT.</li> Patch-latency hos leverandører:</strong> Microsoft / de fleste Linux-distroer inden for 1 uge fra disclosure; Android 2+ måneder afhængigt af OEM; mange embedded-enheder blev aldrig patchet.</li> PMKID-angrebets pakke-antal:</strong> 1 enkelt frame</strong> mod 4-way-handshakens 4 frames — ingen klient-association eller deauth nødvendig.</li> hashcat på GTX 1080 (reference-GPU 2017):</strong> ~400.000 WPA-PSK-kandidater/sek — ~5× hurtigere end 2012.</li> En lejet 8× 1080 Ti-instans (~$4/t i 2017):</strong> ~3M kandidater/sek — rockyou.txt</code> på <5 sekunder.</li> Koordineret disclosure-forløbstid:</strong> 4 måneder fra leverandør-notificering til offentlig release.</li> </ul> Hvad en forsvarer burde have gjort:</strong> patch Android / wpa_supplicant straks, håndhæv HTTPS overalt, så dekrypteret Wi-Fi-trafik er mindre nyttig, begynd at planlægge WPA3-migration.</p> 2022 — WPA3 ruller ud, downgrade-angreb</h2> Standard:</strong> WPA3 (2018) påkrævet til Wi-Fi CERTIFIED-enheder siden 2020. Nøgle-opgraderinger:</p> SAE</strong> (Simultaneous Authentication of Equals) erstatter 4-way-handshake-PSK’en — offline-dictionary-angreb bliver ufremkommelige.</li> 192-bit mode</strong> til Enterprise.</li> Forward secrecy</strong>.</li> PMF</strong> (Protected Management Frames) obligatorisk — neutraliserer deauth-baseret denial-of-service.</li> </ul> Hvad der er nyt for angribere:</strong> WPA3 er ikke brudt, men dens udrulning er for det meste ikke WPA3-kun</strong>. WPA2/3-transition-mode</strong> — default på de fleste AP’er — betyder, at en angriber kan tvinge en downgrade og angribe som WPA2. Det er Dragonblood</strong> (Vanhoef, Ronen, 2019 + opfølgninger): en familie af side-channel- og downgrade-angreb mod SAE. I 2022 lukkede patchede SAE-implementationer for det meste timing-side-channels; downgrade-angrebet virker stadig på mixed-mode-netværk.</p> Også i denne æra:</strong></p> Cloud-skala-cracking</strong>: at leje 8× H100 eller lignende på timebasis gør PMK-dictionary-angreb praktiske på en skala, ingen amatør havde i 2012.</li> Chipset-firmware-sårbarheder</strong> (FragAttacks, 2021): fejl i selve Wi-Fi-stakken, under WPA-laget, lader angribere injicere frames uden at skulle bryde en handshake overhovedet.</li> </ul> Tal (2022):</strong></p> Global udbredelse:</strong> WPA2-only ~60%, WPA3 ~20%, WPA2/3-transition-mode ~15%, WEP <1%.</li> WPA3-understøttelse på nye routere:</strong> ~60% af forbruger-AP’er leveret i 2022 understøttede WPA3 (vs. ~10% i 2020).</li> Dragonblood CVE’er:</strong> 5 (CVE-2019-9494 til CVE-2019-9499).</li> FragAttacks CVE’er:</strong> 12 i 2021-bundlet.</li> hashcat WPA-PSK på RTX 3090:</strong> ~1,2M kandidater/sek.</li> 8× A100-cloud-instans:</strong> ~10M kandidater/sek samlet. rockyou.txt</code> på ~1,5 sekund; et 10 mia.-kandidats mask-angreb på ~17 minutter.</li> Pris pr. milliard PSK-forsøg på spot-cloud-GPU’er:</strong> ~$3–5.</li> 12-tegns fuldt tilfældig PSK-entropi:</strong> 2⁷² ≈ 4,7 × 10²¹. Ved 10M H/s er udtømmende angreb = ~15.000 år</strong>. Sikker.</li> 8-tegns små-bogstav+ciffer PSK-entropi:</strong> 2⁴¹ ≈ 2,2 × 10¹². Ved 10M H/s: ~2,5 døgn</strong>. Ikke sikker.</li> </ul> Hvad en forsvarer burde have gjort:</strong> WPA3-Personal kun (ingen WPA2-transition) på netværk, hvor du kan håndhæve det; PMF påkrævet; lang tilfældig PSK selv med SAE; hold AP-firmware opdateret.</p> 2027 — dagens landskab</h2> Standard:</strong> Wi-Fi 6E (6 GHz) og tidlige Wi-Fi 7-udrulninger. WPA3 næsten universel på nyt gear; legacy WPA2 stadig almindelig i små virksomheder og længe-levende hjemme-netværk.</p> State of the art i angreb:</strong></p> SAE holder.</strong> Intet offentligt, praktisk angreb mod et velkonfigureret WPA3-Personal-netværk i 2027. Dictionary-angreb mod PSK’en er ikke fremkommelige — det er SAE’s pointe.</li> Downgrade-angreb</strong> er den primære ting. Ethvert netværk, der stadig annoncerer WPA2/3-transition, kan angribes som WPA2. Modstandere kigger efter mixed-mode-SSID’er først.</li> 6 GHz åbner ny overflade.</strong> 6 GHz-båndet kræver WPA3 til nye standarder; men legacy-klient-bridging, IoT-enheder uden 6 GHz-understøttelse og fejlkonfigureret co-broadcast-SSID’er skaber inkonsistenser, angribere udnytter.</li> Klient-side-angreb.</strong> Når link-laget er sikkert, flytter angribere op. Rogue-captive-portals der snyder telefoner til at stole på et dårligt certifikat, QR-kode-tilslutning med falske SSID’er, deauth-under-roaming-angreb (sværere nu med PMF, men ikke elimineret).</li> Supply chain.</strong> Firmware-indlejrede bagdøre og vendor-bugs i Wi-Fi-chipsets (FragAttacks-arven) er stadig en varig kilde til exploits.</li> Cloud-cracking er blevet commodity.</strong> Et weekend-langt SAE-offline-angreb (i de tilfælde, hvor offline-angreb er muligt, altså målet kørte en upatched SAE) koster groft prisen på en pæn middag. Det betyder for det meste intet, fordi SAE ikke er reducerbart til offline-dictionary-angreb — men det skubber økonomien på legacy-WPA2-netværk, folk ikke har migreret.</li> </ul> Værktøjer stadig i rotation i 2027:</strong> aircrack-ng (ældre, stadig kanonisk til captures og WPA2), hashcat (cracking), bettercap (Wi-Fi MITM / rogue AP), airgeddon (workflow-lim) og en bølge af ESP32-baserede lomme-værktøjer til opportunistisk deauth og handshake-capture.</p> Tal (2027):</strong></p> Global udbredelse:</strong> WPA3 ~40%, WPA2/3-transition ~35%, WPA2-only ~20%, WEP ~0,5% (lang hale af gammelt gear).</li> Enterprise-andel der kører WPA3-Enterprise 192-bit mode:</strong> stadig <10%. De fleste corporate-netværk er stadig WPA2-Enterprise med PEAP.</li> Ny-enhed WPA3-certificering:</strong> obligatorisk for Wi-Fi 6 siden 2020, Wi-Fi 6E (6 GHz) siden 2022, Wi-Fi 7 fra launch.</li> hashcat WPA-PSK på RTX 5090-klasse enkelt-GPU (2025+):</strong> ~5–8M kandidater/sek.</li> 8× H100-cloud-instans:</strong> ~50M kandidater/sek samlet. rockyou.txt</code> på ~0,3 sekund.</li> SAE (WPA3-Personal) offline-angreb:</strong> ufremkommeligt ved enhver hash-rate — handshaken udleverer ikke en crackbar hash til en aflytter.</li> Pris for at brute-force en svag 8-tegns WPA2-PSK i 2027:</strong> <$10 på spot-cloud-GPU’er.</li> Pris for at brute-force en 12-tegns tilfældig WPA2-PSK:</strong> stadig ~$10⁹ (samme regnestykke som 2022, GPU’er 5× hurtigere → stadig årtusinder).</li> ESP32-S3 “Wi-Fi Nugget” / Flipper Zero-klasse lomme-værktøjer</strong> i cirkulation i 2027: hundredtusinder af enheder. Opportunistisk handshake-capture er trivielt; PSK-cracking er stadig offline på en kraftig host.</li> Deauth-DoS-effektivitet:</strong> nær-nul på PMF-required-netværk; virker stadig mod de ~30% af udrullede AP’er, hvor PMF er “capable”, men ikke “required”.</li> </ul> Bundlinje: mod WPA3-Personal med SAE, PMF påkrævet og en tilfældig PSK</strong> kommer intet af 2027-værktøjssættet ind via link-laget. Mod en typisk 2019-vintage hjemme-router, der stadig kører WPA2 med en svag PSK og WPS valgfrit eksponeret</strong>, er en weekend på en mellem-klasse-GPU rigeligt.</p> Defensiv vejledning for 2027</h2> Det er den del, der betyder mere end al historien.</p> WPA3-Personal SAE-only eller WPA3-Enterprise med EAP-TLS.</strong> Ingen transition-mode på noget netværk, du kan kontrollere. Tjek eksplicit — mange AP’er default til transition.</li> PMF påkrævet, ikke valgfrit.</strong> Protected Management Frames forhindrer deauth-drevne handshake-captures og basal denial-of-service.</li> PSK-længde: tilfældig, ≥ 20 tegn.</strong> SAE gør korte PSK’er sikrere end de plejede at være, men ingen grund til at spille.</li> Slå WPS permanent fra.</strong> Selvom WPS-PIN-angrebet er oldgammelt, leverer mange routere stadig med det aktiveret for “bekvemmelighed”.</li> Gæste-SSID isoleret.</strong> Klient-til-klient-isolation slået til og routet til et separat VLAN uden intern LAN-adgang.</li> IoT-SSID, separat og indelukket.</strong> Billige Wi-Fi-termostater og legetøj er det svageste led på de fleste hjemme-netværk. De får deres eget SSID, deres eget VLAN og ingen rute til noget vigtigt.</li> Firmware-opdateringer på AP’er.</strong> De fleste interessante 2020’er-Wi-Fi-sårbarheder var på chipset-niveau; rettelsen er altid en firmware-opdatering. Køb AP’er fra en leverandør, der leverer dem.</li> Antag at link-laget vil fejle og forsvar dig over det.</strong> HTTPS overalt, klient-certs på alt, der betyder noget, VPN eller Tailscale til fjernadgang. Når (ikke hvis) nogen bryder din Wi-Fi, skal lag 4+ stadig holde.</li> </ul> Hvad der forblev det samme gennem 25 år</h2> Tre mønstre gentager sig ved hver generation:</p> Kryptografien er næsten altid stærkere end udrulningerne.</strong> WEP var en design-fejl; WPA2 og WPA3 er blevet brudt af implementerings-fejl, downgrade-stier og side-channels — ikke af rene krypto-svagheder.</li> Defaults betyder mere end kapabiliteter.</strong> WPS tændt som default, WPA2/3-transition-mode tændt som default, gæste-netværk uden isolation som default — det er det, angribere faktisk finder, i skala.</li> Angriberen flytter altid op i stakken.</strong> Når link-lags-sikkerheden forbedres, skifter angreb til captive portals, falske certs, klient-fejlkonfigurationer og phishing. Ingen mængde WPA3 retter brugeren, der klikker “Stol på” på evil-twin’ens falske certifikat.</li> </ol> Coda</h2> Hvis denne posts forfader på dette site, fra 2010, var “Hvordan man hacker et trådløst netværk” og fokuserede på WEP med aircrack-ng</code>, er 2027-versionen tættere på “Hvordan man tænker om Wi-Fi-sikkerhed” og fokuserer på konfiguration, patching og realistisk trussels-modellering. Kryptografien har gjort sit arbejde. Lagene omkring den er den interessante front nu.</p> Test dine egne netværk — eller netværk, du er autoriseret til at teste — test ikke nogen andens. Samme lov, der gjaldt i 2002, gælder i 2027.</p> nemboks.dk — få din digitale post (mit.dk, e-Boks) sendt direkte til din e-mail 2026-04-22T00:00:00+00:00 TL;DR —</strong> nemboks.dk</a> videresender digital post</strong> (fra mit.dk</a> og e-Boks</a>) direkte til din e-mail. Problemet, det løser: digital post er i teorien “push”, men i praksis “pull” — du skal stadig logge ind med MitID, åbne en app og klikke rundt for at læse et brev fra SKAT eller kommunen. Nemboks laver det til en e-mail, der lander i den indbakke, du i forvejen bor i — med PDF’en vedhæftet. Bygget til danske SMV’er, hvor samme virksomhed</code> modtager post for flere selskaber eller medarbejdere, og hvor revisorer, bogholdere og ejendomsadministratorer vil have digital post samme sted som al anden e-mail. Gratis beta; efter beta koster det 39 kr/md på årlig betaling, 49 kr/md månedlig.</p> Problemet med dansk digital post</h2> Siden 2014 er kommunikation fra det offentlige digital som udgangspunkt. Det betyder, at hvis din kommune, SKAT, Udbetaling Danmark eller FerieKonto skal fat i dig, lægger de brevet i enten mit.dk</a></strong> (den offentlige portal) eller e-Boks</a></strong> (historisk set den mest brugte private portal, nu koblet til Digital Post).</p> I princippet er det fint: samlet, sporbart, ingen papir. I praksis er der en masse friktion:</p> Du skal logge ind med MitID hver gang.</strong> Hvert skattebrev, hver p-afgift, hver feriepenge-besked ligger bag en MFA-flow.</li> Apps notificerer dig, men notifikationerne er tynde.</strong> “Du har ny post” — ikke emnelinje, ikke afsender, ikke nok til at prioritere.</li> Der er ingen indbygget videresendelse.</strong> Du kan ikke sige “send alt fra SKAT til min bogholder på bogholder@firma.dk</code>”.</li> Virksomheder får det værste af begge verdener.</strong> En CVR-registreret virksomhed har sin egen mit.dk / e-Boks-indbakke. Hvis indehaveren ikke tjekker den, er der ingen, der gør.</li> </ul> E-mail er omvendt standard-indbakken for små virksomheder: delte postkasser, videresendelsesregler, arkivering, filtre, søgning. Nemboks bygger broen imellem.</p> Hvad Nemboks gør</h2> Når Nemboks er sat op, logger den på din mit.dk / e-Boks på dine vegne, tjekker for ny post og sender hvert nyt brev videre — som en rigtig e-mail med PDF’en vedhæftet</strong> — til den eller de adresser, du har konfigureret.</p> En e-mail pr. brev.</strong> Emne = afsender + emne. Brødtekst = tekst-preview. Vedhæftning = PDF’en.</li> Flere selskaber pr. konto.</strong> Hvis du er revisor for flere CVR’er, bor de alle under samme Nemboks-dashboard.</li> Flere destinationer pr. selskab.</strong> Send f.eks. alt fra SKAT til bogholderen, resten til ejeren.</li> Originalen bliver liggende i mit.dk / e-Boks.</strong> Intet slettes — Nemboks læser kun.</li> Logger hver videresendelse.</strong> For revision og ro i maven.</li> </ul> Det praktiske resultat: revisoren eller bogholderen, der allerede bor i Outlook eller Gmail, holder op med at skifte kontekst til en portal en gang om ugen.</p> Hvem det er til</h2> Nemboks er bygget til danske SMV’er, især:</p> Revisorer og bogholdere.</strong> Kunden giver adgang én gang; derefter bliver hvert SKAT-brev for hver kunde til en e-mail i den delte indbakke.</li> Ejendomsadministratorer.</strong> En enkelt administrator kan sidde med post for dusinvis af ejendoms-A/S og -ApS.</li> Smv-indehavere.</strong> Enkeltmandsvirksomheden eller to-mands-ApS, hvor ejeren hellere vil have brevet fra kommunen samme sted som sin kunde-mail.</li> </ul> Stakken</h2> For de nysgerrige:</p> Rails 8</strong> på Ruby 3.4 med Hotwire (Turbo + Stimulus) og Tailwind til dashboardet.</li> PostgreSQL</strong> til persistens.</li> Auth0</a></strong> til autentificering. Brugerne logger på med Google, Microsoft eller e-mail+kodeord — ingen separat Nemboks-kodeord at glemme.</li> Stripe</a></strong> til abonnementsstyring, inkl. deres hostede kundeportal til selv-betjent kortopdatering og opsigelse.</li> Postmark</a></strong> til transaktionel e-mail — de er kategoriens standard for “e-mail der skal lande i indbakken”, hvilket er hele pointen med en videresendelses-tjeneste.</li> Docker + Kamal</strong> til deployment. Zero-downtime rollouts på en lille flåde; ingen Kubernetes at drifte.</li> Cloudflare Pages</strong> til det statiske marketing-site på nemboks.dk</a>.</li> </ul> Opdelingen — Rails-app på Kamal, marketing-site på Pages — er bevidst. Marketing-sitet skal være billigt, hurtigt og tungt cached; Rails-appen skal have database og baggrundsjobs. At køre dem som to separate deployments holder hver af dem simpel.</p> Pris</h2> Gratis beta</strong>, mens tjenesten stabiliseres.</li> Efter beta: 39 kr/md</strong> på årlig betaling, 49 kr/md</strong> månedlig — excl. moms. Flad pris pr. selskab; ingen pris pr. brev.</li> 60 dages gratis prøveperiode</strong> til nye kunder efter beta.</li> </ul> Ofte stillede spørgsmål</h2> Må Nemboks læse min mit.dk / e-Boks?</h3> Ja — som indbakke-ejer giver du Nemboks lov til at læse på dine vegne. Nemboks læser kun; intet slettes, besvares eller markeres som læst uden at du har konfigureret det.</p> Er det GDPR-compliant?</h3> Nemboks behandler persondata på dine vegne. Som kunde er du dataansvarlig; Nemboks er databehandler, og der er en standard databehandleraftale (DPA) at underskrive. Alle data opbevares i EU.</p> Hvad sker der med det originale brev i mit.dk / e-Boks?</h3> Det bliver liggende. Nemboks er read-only.</p> Kan jeg videresende til flere e-mailadresser?</h3> Ja. Hvert selskab kan have flere modtagere, og du kan sende forskellige afsendere til forskellige adresser (f.eks. alt fra SKAT til bogholderen).</p> Virker Nemboks for privatpersoner?</h3> Det nuværende fokus er danske virksomheder (CVR). En privat-plan kommer måske senere.</p> Hvad hvis Nemboks går ned?</h3> Din post lander stadig i mit.dk / e-Boks som normalt; Nemboks videresender bare ikke, før tjenesten er tilbage. Intet går tabt.</p> Hvordan opsiger jeg?</h3> Via Stripes kundeportal inde fra dashboardet. Ingen e-mail, intet telefonopkald.</p> Hvorfor bygge det</h2> Digital post virker. Det er sikkert, sporbart, og jeg vil hellere have et SKAT-brev i mit.dk end en brun kuvert. Men brugerfladen er designet til en borger, der læser en håndfuld breve om året — ikke til en virksomhed, der får dusinvis om ugen på tværs af flere CVR’er. E-mail løser “dusinvis om ugen på tværs af flere postkasser” udmærket — filtre, regler, delte indbakker, søgning — så den mindst interessante, men mest nyttige bro er at få brevene ud af portalen og ind i e-mailen med PDF’en vedhæftet, uden at nogen skal logge ind hver gang.</p> Det er Nemboks.</p> Sådan afspiller du Spotify på en Logitech Squeezebox i 2026 2026-04-22T00:00:00+00:00 TL;DR —</strong> Det officielle Spotify-plugin, Logitech leverede med Squeezebox, holdt op med at virke, da Spotify lukkede libspotify</code>-API’en i 2022. I 2026 er der to fungerende veje til at få Spotify på en Squeezebox Classic, Touch, Boom, Radio eller Transporter</strong>: (1) Logitech Media Server + Spotty-plugin’et</a></strong> (nu omdøbt Spotty</code> / nogle gange Spotty-XL</code>), der bruger Spotifys Web API plus librespot</code> under motorhjelmen, eller (2) kør spotifyd</a></strong> på samme host som LMS og peg LMS på den som generisk lydkilde. Vej 1 er den, du vil bruge, medmindre du har en grund til andet. Dette indlæg gennemgår den.</p> Hvad skete der med det officielle plugin</h2> Squeezebox-hardware gik end-of-life hos Logitech i 2012, men softwaren — Logitech Media Server (LMS)</strong>, det der faktisk streamer musik til enhederne — er blevet community-vedligeholdt siden. I årevis leverede den et officielt “Spotify”-plugin, der brugte Spotifys nu udfasede libspotify</code> C-bibliotek. Da Spotify lukkede libspotify</code> i 2022, holdt det plugin op med at virke, og Spotify har ikke leveret en erstatning til tredjeparts-indbyggede enheder.</p> Community’et udfyldte hullet:</p> librespot</code></strong> — en open-source Rust-reimplementering af Spotify Connect-klientprotokollen. Grundlaget for de fleste moderne tredjeparts-Spotify-integrationer.</li> Spotty-plugin til LMS</strong> — pakker librespot</code> og Spotifys Web API ind i et LMS-plugin. Præsenterer Spotify-browsing, søgning, playlister og afspilning inde i Squeezebox-UI’et (både enheds-skærmen og LMS-web-UI’et).</li> spotifyd</strong> — en selvstændig librespot</code>-baseret dæmon, der fremstår som et Spotify Connect-mål. Din telefon ser den som en højttaler, du caster til den, og dens lydudgang går et sted hen, hvor LMS kan samle det op.</li> </ul> Vej 1 (anbefalet): Spotty-plugin på LMS</h2> Dette er den reneste oplevelse og den, der føles native på Squeezeboxen. Du søger og browser fra Squeezebox-fjernbetjeningen eller Touch-skærmen, og det Virker Bare.</p> 1. Få LMS op at køre</h3> Hvis du ikke allerede kører LMS, så installér det på en altid-tændt maskine — en Raspberry Pi, et NAS med Docker eller en lille Linux-boks er ideelt.</p> # Debian/Ubuntu — hent den nyeste .deb fra community-repoet wget https://downloads.slimdevices.com/LogitechMediaServer_v8.x/logitechmediaserver_<latest>_amd64.deb sudo apt install ./logitechmediaserver_<latest>_amd64.deb sudo systemctl enable --now logitechmediaserver </code></pre> Eller via Docker — lmscommunity/logitechmediaserver</code> er et vedligeholdt image:</p> docker run -d --name lms \ --network host \ -v lms-config:/config \ -v /sti/til/musik:/music:ro \ lmscommunity/logitechmediaserver:latest </code></pre> Åbn http://<host>:9000/</code>, og du skulle se LMS-web-UI’et. Dine Squeezebox-enheder på samme LAN skal dukke op under Players</strong> automatisk.</p> 2. Installér Spotty</h3> I LMS-web-UI’et: Settings → Plugins → Install new plugins</strong> og kryds Spotty</strong> af (forfatter: Michael Herger). LMS henter, installerer og genstarter. Efter genstart har du et Spotty</strong>-punkt i Settings → Advanced → Spotty</strong>.</p> 3. Autoriser Spotty med din Spotify-konto</h3> I Settings → Advanced → Spotty</strong> klik Add account</strong>.</li> Spotty starter et OAuth-flow via Spotifys Web API — du logger ind én gang i en browser, godkender adgangen, og tokenet gemmes på LMS-serveren.</li> Du skal bruge Spotify Premium</strong> til afspilning. (Det er en Spotify-side-grænse: librespot</code> kan autentificere med Free, men fuld-kvalitets-afspilning er kun til Premium.)</li> </ul> 4. Afspil noget</h3> På selve Squeezebox-enheden: Home → My Music → Spotty</strong> (eller Home → Music Library → Spotty</strong>, afhængigt af din LMS-version) — browsing af playlister, søgning, start et nummer. På Squeezebox Touch virker artwork på skærmen. På Classic virker tekst-UI’et. På Radio og Boom styrer du det fra web-UI’et eller apps som Squeeze Commander</a> / Squeezer</a>.</p> Spotty tilføjer også Squeezebox-enheder som Spotify Connect-mål</strong> — det betyder, at du kan caste fra din telefon-Spotify-app til “Stue-Squeezeboxen” native, på samme måde som du ville caste til en Sonos eller en Google Home.</p> Vej 2: spotifyd som Connect-bro</h2> Brug denne, hvis Spotty ikke vil installere (gammel LMS-version, gammel Perl, mærkeligt OS) eller du specifikt vil have Spotify Connect-adfærd uden Spotty.</p> # Debian/Ubuntu sudo apt install spotifyd # eller fra kilden: cargo install spotifyd </code></pre> Konfigurér /etc/spotifyd.conf</code> med dine Spotify-credentials, en backend (alsa</code>, pulseaudio</code> eller pipe</code>) og et enhedsnavn. Start dæmonen:</p> sudo systemctl enable --now spotifyd </code></pre> Fra din telefon, cast til den spotifyd</code>-navngivne enhed. Lyden kommer ud af hosten.</p> For at få den lyd ind i en Squeezebox, pipe spotifyd</code> til en FIFO og afspil FIFO’en i LMS:</p> # spotifyd.conf backend = "pipe" device = "/var/run/spotifyd.pipe" </code></pre> Tilføj derefter FIFO’en som en File system music folder</strong> i LMS og afspil den som en live-stream.</p> Det er klodset og har ~1 s forsinkelse i forhold til Spottys tætte integration. Brug det kun, hvis vej 1 ikke virker for dig.</p> Virker på hvilke Squeezeboxe?</h2> Spotty virker på alle Squeezebox-enheder, der taler med LMS:</p> Squeezebox Classic / Squeezebox v3</strong> (tekstdisplay) — tekst-UI-browsing og afspilning.</li> Squeezebox Touch</strong> — farvetouchskærm, artwork, hele UI’et.</li> Squeezebox Boom</strong> — tekst-UI, samme som Classic.</li> Squeezebox Radio</strong> — tekst-UI, indbygget højttaler.</li> Squeezebox Duet / Controller</strong> — controllerens UI virker; afspilning går til Receiveren.</li> Transporter</strong> — fuld understøttelse.</li> piCorePlayer / SqueezeLite på Pi</strong> — ja, det er software-Squeezeboxe, og Spotty streamer fint til dem.</li> </ul> Så længe enheden kan forbinde til LMS, kan Spotty fodre den.</p> Ofte stillede spørgsmål</h2> Skal jeg have Spotify Premium?</h3> Ja, til afspilning. librespot</code> (og dermed Spotty) kræver en Premium-konto for at afkode lyd. Spotify Free-konti kan autentificere, men kan ikke afspille.</p> Virker “Squeezeboxen som Spotify Connect-højttaler”?</h3> Ja, med Spotty installeret. Hver Squeezebox-player dukker op i Spotify-appens enhedsvælger som et Connect-mål.</p> Virker hi-res / lossless?</h3> Spotify tilbyder ikke selv lossless på standardplaner (Hi-Fi har været “kommer snart” i årevis). Spotty afspiller, hvad Spotify serverer — Ogg Vorbis 320 kbps på Premium — og Squeezeboxen håndterer det native.</p> Gapless afspilning?</h3> Ja, Spotty understøtter gapless.</p> Går det i stykker, hvis Spotifys Web API ændrer sig?</h3> Ja, lejlighedsvis — Spotify roterer jævnligt OAuth-scopes eller udfaser endpoints, og Spotty får en patch-release. Hold plugin’et opdateret.</p> Kan jeg køre LMS på samme boks som mit NAS?</h3> Absolut. LMS er let (~200 MB RAM, minimal CPU undtagen under bibliotek-scanninger). At køre det ved siden af Samba eller på en homelab-SBC er det almindelige setup.</p> Er det det samme som “piCorePlayer”?</h3> piCorePlayer er en lille Linux-distribution, der gør en Raspberry Pi til en Squeezebox-kompatibel player (via SqueezeLite). Den erstatter ikke LMS — du skal stadig bruge LMS som server. piCorePlayer + LMS + Spotty er en meget almindelig 2026-stak for folk, hvis oprindelige Squeezebox-hardware endelig døde.</p> Hvad du gør, hvis din Squeezebox slet ikke vil forbinde til LMS</h2> To ting at tjekke først:</p> mDNS / multicast på tværs af dit netværk.</strong> Moderne Wi-Fi-routere blokerer ofte multicast mellem SSID’er eller til kablede hosts. Sæt Squeezeboxen og LMS på samme subnet/VLAN med multicast tilladt.</li> SlimProto-porten (3483/udp og 3483/tcp).</strong> Det er det, Squeezeboxen bruger til at finde LMS. Ikke blokeret af noget fornuftigt, men værd at tjekke, hvis du kører en stram firewall.</li> </ol> Derudover er Squeezebox-community’et stadig aktivt — forums.slimdevices.com</a> og LMS Community GitHub</a> er, hvor problemer bliver løst.</p> Squeezebox-hardware blev udfaset for femten år siden. Takket være LMS, Spotty og librespot</code> afspiller den stadig Spotify bedre end de fleste “smarte højttalere”, der sælges nye i 2026.</p> elpriser.org — danske elpriser time for time 2026-04-20T00:00:00+00:00 TL;DR —</strong> elpriser.org</a> viser den reelle elpris time for time i Danmark</strong> — ikke kun spotprisen. Den samler Nord Pool-spotprisen, din lokale nettarif (netselskab</code>), Energinets system- og transmissionstariffer, elafgiften og 25 % moms. Data kommer fra Energi Data Service</a> og opdateres dagligt, når Nord Pool offentliggør de kommende 24 timer omkring kl. 13. DK1 (Vestdanmark) og DK2 (Østdanmark). Dansksproget, gratis, intet login.</p> Hvad koster el faktisk i Danmark?</h2> “Spotprisen”, du ser på de fleste energidashboards, er kun én del af regningen. Den pris, du rent faktisk betaler pr. kWh, består af seks elementer:</p> Spotpris</strong> — sættes time for time på Nord Pool-markedet for det kommende døgn.</li> Nettarif</strong> — betales til dit lokale netselskab. Varierer efter selskab og tidspunkt (lav-, mellem- og spidslast).</li> Systemtarif</strong> — betales til Energinet, den danske TSO.</li> Transmissionstarif</strong> — betales også til Energinet.</li> Elafgift</strong> — statslig afgift på forbrug.</li> Moms</strong> — 25 % oven i alt det andet.</li> </ol> De fleste prissider viser kun det første tal. Nogle få viser ét eller to mere. Ingen, jeg kunne finde, viste alle seks time for time, for begge prisområder, med den rigtige nettarif automatisk valgt for brugerens netselskab. Det er præcis det, elpriser.org gør.</p> De to prisområder: DK1 og DK2</h2> Danmark er delt i to elprisområder geografisk — Storebælt skiller dem — og de har ofte forskellig pris i samme time:</p> DK1 — Vestdanmark.</strong> Jylland og Fyn. Mere vind-domineret.</li> DK2 — Østdanmark.</strong> Sjælland, Lolland, Falster, Møn og Bornholm. Tættere forbundet med Sverige (SE4) og Tyskland.</li> </ul> Når vinden blæser kraftigt i Jylland, kan DK1 være billig, mens DK2 er dyr. Når en forbindelse er nede, vokser forskellen yderligere. elpriser.org viser begge områder side om side.</p> Hvilket netselskab har du?</h2> Du kan ikke selv vælge dit netselskab — det afhænger af din adresse — men den nettarif, de opkræver, er en betydelig del af regningen, og den varierer med 15–25 øre/kWh i spidslast</strong> mellem billigste og dyreste, hvilket svarer til ~500–1.000 kr/år</strong> for en typisk husstand.</p> Groft rangeret spidslast-tariffer pr. 2025:</p> Område</th> Netselskab</th> Spidslast-tarif (øre/kWh)</th></tr></thead> DK1</td> RAH Net</td> ~33</td></tr> DK1</td> Trefor</td> ~37</td></tr> DK1</td> N1</td> ~46</td></tr> DK2</td> Cerius</td> ~47</td></tr> DK2</td> Radius</td> ~65</td></tr> </tbody></table> Mindre selskaber (Konstant, Nord Energi, Vores Elnet, El-net Kongerslev og andre) har egne tariffer. På elpriser.org vælger du dit eget, og den all-in time-for-time-pris tilpasser sig.</p> Du kan ikke skifte netselskab, men du kan</strong> flytte forbrug — vaskemaskine, opvaskemaskine, EV-ladning, varmepumpe — ned i lavsats-timerne. Time-grafen findes til lige præcis det.</p> Historiske yderpunkter</h2> Rekord-høj:</strong> 16,69 kr/kWh (spotpris ex. moms) i DK2, kl. 19 den 5. september 2022 under energikrisen.</li> Rekord-lav:</strong> −2,76 kr/kWh i DK1, kl. 14 den 2. juli 2023, hvor vindproduktionen overskød forbruget.</li> </ul> Negative priser er ikke en fejl: når produktionen er høj og forbruget lavt, betaler producenterne forbrugerne for at aftage strømmen. Moderne prisstyrede varmepumper og EV-ladere kan læne sig ind i det.</p> Sådan er elpriser.org bygget</h2> Statisk HTML</strong>, genskabt én gang om dagen efter Nord Pools day-ahead-auktion omkring kl. 13 CET.</li> Datakilde</strong>: Energi Data Service</a>, Energinets åbne data. Ingen API-nøgler nødvendige.</li> Strukturerede data</strong>: schema.org/WebApplication</code> og FAQPage</code> udsendes på hver side, så Google kan vise priserne direkte i søgeresultater og AI-oversigter.</li> Hosting</strong>: en lille origin bag Cloudflare. Cachebar hele døgnet; purges ved det daglige rebuild.</li> Sprog</strong>: kun dansk. Domænenavnet burde have været et fingerpeg.</li> </ul> Det hele er et enkeltsporet værktøj: ingen tracking, intet login, ingen nyhedsbrev-popover, ingen “10 måder at spare på strømmen”-lister.</p> Ofte stillede spørgsmål</h2> Hvor ofte opdaterer elpriser.org?</h3> Én gang om dagen, efter at Nord Pools day-ahead-auktion offentliggør næste døgn omkring kl. 13 CET. Intradag-justeringer vises ikke; de fleste forbrugere afregnes alligevel efter day-ahead-prisen.</p> Er prisen med eller uden moms?</h3> Med. Headline-tallet på elpriser.org er all-in pr. kWh: spotpris + tariffer + afgift + 25 % moms. Du kan folde det ud og se opdelingen.</p> Hvorfor er priserne forskellige i DK1 og DK2?</h3> Danmark har to fysisk adskilte elprisområder, forbundet via Storebælt. Når forbindelsen er fuldt udnyttet, eller når vindproduktionen adskiller sig markant mellem øst og vest, clearer de to områder på forskellige Nord Pool-priser.</p> Kan jeg se opdelingen af hver komponent?</h3> Ja. Hver time-celle kan foldes ud for at vise spotpris, hver tarif-komponent, elafgift og moms.</p> Får jeg reelt negative priser, når engrosprisen bliver negativ?</h3> Det afhænger af din kontrakt. Rene spotpris-kontrakter videregiver Nord Pools råpris — tariffer og afgift gælder stadig, så all-in-prisen kan gå svagt negativ eller bare meget lav. Fastpris-kontrakter gør ikke.</p> Hvorfor kun dansk?</h3> Data, regulering, netselskabs-strukturen og målgruppen er alle danske. En engelsk version ville oversætte kontekst, ikke indhold.</p> Hvor kommer data fra?</h3> Energi Data Service</a> (Nord Pool-spot) og Energinets tarifdata. Begge er officielle, offentlige datasæt fra den danske TSO.</p> Lille, fokuseret, intet login, ingen tracking. Sådan bør forbruger-energiværktøjer se ud.</p> winniemethmann.com — fra WordPress til Astro 2026-04-19T00:00:00+00:00 TL;DR —</strong> winniemethmann.com</a> er portfolien for en dansk madfotograf og opskriftsudvikler. I et årti var det et WordPress-site. Jeg byggede det om oven på Astro</a> med content collections</strong> (typet Markdown) i stedet for et CMS, Sharp + AVIF</strong> til billedpipelinen og Astros i18n-routing</strong> (dansk som standard, engelsk på /en/</code>). Build-tid: ~30 sekunder. Output: ~70 % mindre. Intet admin-panel, ingen plugin-opdateringer, ingen bot-prøvet login-endpoint.</p> Hvorfor væk fra WordPress</h2> For en portfolio, der opdateres et par gange om måneden, lavede WordPress for meget:</p> PHP-runtime og MySQL</strong> for et site, der i praksis er statisk.</li> Titusindvis af plugins</strong> til billedgallerier, kontaktformularer, SEO og caching — hver med sin egen opdateringskadence og sikkerhedshuller.</li> Et halvt-forket tema</strong> med patches, ingen huskede hvorfor var der.</li> Et admin-login-endpoint</strong>, der blev prøvet flere tusind gange i døgnet af bots.</li> Gentagne cache-kvaler</strong>, hver gang CDN og plugins var uenige.</li> </ul> Konkret betød det at droppe WordPress:</p> Ingen admin-panel at holde patchet.</strong> WordPress-core, plugin-opdateringer, tema-opdateringer — væk.</li> Ingen database.</strong> Indholdet ligger som Markdown i repoet.</li> Ingen login-flade, bots kan prøve.</strong> Der findes ikke en /wp-admin/</code> længere.</li> ~10× hurtigere sideindlæsning</strong> uden cache-lag.</li> ~70 % mindre samlet build-størrelse</strong> — vi skiftede håndeksporterede JPEG’er ud med AVIF med fornuftige srcset</code>-breakpoints.</li> </ul> Til gengæld mister du den ikke-tekniske redigering. I praksis betød det ingenting: ejeren var gladere for at redigere Markdown end for at kæmpe med WordPress’ blok-editor.</p> Hvorfor Astro</h2> Jeg overvejede Hugo, 11ty, Next.js static export og SvelteKit. Astro vandt på tre konkrete punkter:</p> Content collections.</strong> En typet, skema-kontrolleret måde at beskrive et portfolio-projekt som en mappe med fotos plus lidt front-matter. Buildet fejler højlydt, hvis noget ikke overholder skemaet. Intet CMS nødvendigt.</li> <Image></code>-komponenten.</strong> Astros indbyggede billedpipeline håndterer AVIF + JPEG-fallback + srcset</code> + width</code>/height</code> med en one-liner. Sharp er motoren under.</li> Islands-arkitektur — ikke relevant her.</strong> Siden har ingen interaktive komponenter, så den sender stort set ingen JavaScript.</li> </ol> Content collections, ikke et CMS</h2> Hvert portfolio-projekt er en mappe under src/content/portfolio/</code> med et front-matter-skema:</p> src/content/portfolio/ ├── 2024-kogebogs-editorial/ │ ├── index.mdx │ ├── cover.jpg │ ├── 01.jpg, 02.jpg, … └── 2023-forarets-katalog/ ├── index.mdx ├── cover.jpg └── 01.jpg … </code></pre> index.mdx</code>’s front-matter deklarerer titel, kategori, år og forsidebillede. Astro håndhæver skemaet ved build-tid via defineCollection</code></a> med et Zod-skema. Hvis et projekt mangler et forsidebillede eller har en dårlig kategori, fejler buildet.</p> Kategorier: madfotografi, opskriftsudvikling, interiør- og haveproduktion, editorial, kogebøger og mode</strong>. At tilføje et nyt projekt er mkdir</code> + cp .jpg</code> + en kort YAML-front-matter-blok. Ingen admin-UI, ingen database-migration, ingen cache at invalidere.</p> Billedpipeline: Sharp + AVIF</h2> Madfotografi står og falder med billedkvalitet. Astros <Image></code>-komponent — drevet af Sharp</a> — genererer:</p> AVIF</strong> som primært format. Stort set alle moderne browsere understøtter det nu (se caniuse</a>).</li> JPEG</strong>-fallback med matchende srcset</code>-breakpoints (320, 640, 960, 1280, 1920 px).</li> Eksplicitte width</code>- og height</code>-attributter, så der er nul layout shift, mens billederne loader.</li> loading="lazy"</code> til billeder under folden og fetchpriority="high"</code> til heroet.</li> </ul> Tal</strong>: en typisk portfolio-side gik fra ~4,8 MB håndeksporterede JPEG’er til ~1,4 MB AVIF — omkring 70 % reduktion — uden synligt kvalitetstab i de viste størrelser.</p> i18n — dansk som standard, engelsk på /en/</h2> Astros i18n-routing sidder i astro.config.mjs</code>:</p> export default defineConfig({ i18n: { defaultLocale: "da", locales: ["da", "en"], routing: { prefixDefaultLocale: false }, }, }); </code></pre> Det giver:</p> /</code> for dansk (standard, uden præfiks).</li> /en/</code> for engelsk.</li> Hvert indholds-entry deklarerer sit sprog via sin collection og filnavn.</li> <link rel="alternate" hreflang></code> og sitemap genereres fra samme kilde.</li> </ul> Indlæg og portfolio-entries uden oversættelse dukker simpelthen ikke op i det andet sprogs routing — der er ingen forkert-sprog-404.</p> Deployment og build</h2> Output</strong>: fuldt statisk, udgivet som almindelige filer bag Cloudflare.</li> Build-tid</strong>: ~30 sekunder fra koldt cache, ~6 sekunder inkrementelt.</li> Ingen server, ingen database, ingen løbende kørselstid.</strong></li> </ul> Målbare forbedringer</h2> Mål</th> WordPress (før)</th> Astro (efter)</th></tr></thead> Build / deploy-tid</td> ikke relevant</td> ~30 s koldt, ~6 s varmt</td></tr> Typisk sidestørrelse (portfolio-side)</td> ~4,8 MB</td> ~1,4 MB</td></tr> Largest Contentful Paint</td> ~2,8 s</td> ~0,9 s</td></tr> Time to Interactive</td> ~3,5 s</td> ~1,1 s</td></tr> JS sendt til klienten</td> ~220 KB</td> ~0 KB</td></tr> Plugins at holde patchet</td> 14</td> 0</td></tr> </tbody></table> Ofte stillede spørgsmål</h2> Kan en ikke-teknisk ejer stadig redigere siden?</h3> Ja, til tekstændringer. At redigere Markdown i GitHubs web-editor er i praksis lettere end WordPress’ blok-editor. For nye portfolio-projekter er workflowet: træk billeder ind i en mappe, skriv en lille front-matter-blok, commit. Er det for teknisk, kan man bolte en minimal admin på (Decap CMS, Sveltia CMS eller Keystatic).</p> Hvad med SEO efter flytningen?</h3> URL’er blev bevaret, hvor det var muligt. Manglende gamle stier omdirigeres via Cloudflare-regler. Sitemap genereres ved hvert build, og strukturerede data (Person</code>, ImageGallery</code>, Article</code>) udsendes pr. side.</p> Hvorfor Astro og ikke Hugo?</h3> Hugo er hurtigere og simplere til ren blogging, men Astros typede content collections og førsteklasses <Image></code>-komponent vandt i det her tilfælde. Til x2q.net</a> selv endte jeg senere med Zola — men til en portfolio med tung billedpipeline var Astro det rigtige valg.</p> Hvordan holdes billederne organiseret?</h3> Hvert portfolio-projekt har sin egen mappe. Git-repoet er CMS’et. git log</code> fortæller, hvornår et billede blev tilføjet, og hvorfor.</p> Er buildet deterministisk?</h3> Ja. Samme input giver bit-for-bit identisk output. Sharp er pinned i package.json</code>; det samme er Astro. CI kører på Node LTS.</p> Hvis du sidder med et WordPress-site, der laver langt mindre, end dets infrastruktur antyder, er Astro en eftermiddag værd.</p> apextowww.com — gratis apex-til-www-omdirigering 2026-04-18T00:00:00+00:00 TL;DR —</strong> DNS tillader ikke CNAME</code>-records på zoneapex (RFC 1034 §3.6.2</a>). Det er derfor hostingplatforme som Netlify, Vercel, Cloudflare Pages, Firebase og Heroku beder dig om at sætte www.eksempel.dk</code> op med en CNAME</code> og lader eksempel.dk</code> (selve apex) være et problem, du selv løser. apextowww.com</a> løser det: peg to A</code>-records og to AAAA</code>-records mod tjenesten, og den udsteder et Let’s Encrypt-certifikat til dit apex og 301</code>-omdirigerer hver forespørgsel til https://www.ditdomæne.tld/</code> — med sti og querystring bevaret. Gratis, ingen oprettelse, ingen konto.</p> Hvorfor du ikke kan sætte en CNAME på apex</h2> DNS-specifikationen er entydig: en zoneapex (det “nøgne” domæne som eksempel.dk</code>) skal have en SOA</code>-record og som regel NS</code>-records. CNAME</code> er defineret som et alias, der skal stå alene — den må ikke sameksistere med de SOA</code>- og NS</code>-records, som apex er forpligtet til at have. Derfor kan du godt CNAME www.eksempel.dk → mitsite.netlify.app</code>, men du kan ikke</strong> CNAME eksempel.dk → mitsite.netlify.app</code>.</p> Der findes workarounds, og alle er en smule akavede:</p> ALIAS- / ANAME-records.</strong> Leverandørspecifikke hos Cloudflare, Route 53, DNSimple, NS1 og andre. De virker ved at slå målet op bag kulisserne og returnere en A</code>/AAAA</code>. Fint, hvis din DNS-udbyder understøtter det; ubrugeligt, hvis ikke.</li> Fladning på udbyderniveau.</strong> Cloudflares “CNAME flattening” er præcis det, gjort automatisk.</li> Din egen altid-tændte VPS med 301 → www</code>.</strong> Det var det, jeg gjorde for flere domæner — både overkill og en lille vedligeholdelsesskat.</li> </ul> apextowww er den fjerde mulighed: en andens altid-tændte omdirigerer, driftet for dig.</p> Hvad apextowww gør</h2> Nøjagtig én ting: en 301 Moved Permanently</code> fra https://ditdomæne.tld/noget?x=y</code> til https://www.ditdomæne.tld/noget?x=y</code>.</p> TLS</strong> udstedes automatisk ved første forespørgsel via Let’s Encrypts HTTP-01-challenge. Ingen ACME-klient at køre selv.</li> IPv4 + IPv6</strong> som dual-stack fra starten. Begge record-typer er påkrævet.</li> HTTP/1.1, HTTP/2 og HTTP/3</strong> serveres. Selve omdirigeringen er lille, så protokolversion betyder mindre, men det hjælper first-paint, når omdirigeringen ligger i den kritiske sti.</li> Sti og querystring</strong> bevares, så deep links stadig virker.</li> Ingen oprettelse, intet login, ingen konto.</strong> Hvis DNS er peget korrekt, virker det bare.</li> </ul> Sådan sætter du det op</h2> Gå til apextowww.com</a> og kopiér de aktuelle IP-adresser (to IPv4, to IPv6).</li> I din DNS-udbyder: sæt A</code>-records på dit apex, der peger på de to IPv4-adresser. Fjern eventuelle eksisterende A</code>-records på apex.</li> Sæt AAAA</code>-records på dit apex, der peger på de to IPv6-adresser.</li> Sørg for, at www.ditdomæne.tld</code> stadig peger på din rigtige host (CNAME til Netlify / Vercel / Pages / osv.).</li> Vent på DNS-propagering. Besøg http://ditdomæne.tld/</code> — den skal nu 301-omdirigere til https://www.ditdomæne.tld/</code>.</li> </ol> apextowww-siden har platform-specifikke guides under /netlify-apex-domain-redirect/</code>, /vercel-apex-domain-redirect/</code>, /cloudflare-pages-apex-redirect/</code>, /firebase-hosting-apex-redirect/</code> og /heroku-apex-domain-redirect/</code>.</p> Stak</h2> Hetzner ARM64</strong>-servere for billig, strømbesparende compute. ARM64 er ~30 % billigere pr. vCPU hos Hetzner end x86 og kører omdirigereren uden at ryste på hånden.</li> Caddy-agtig automatisk TLS</strong> med Let’s Encrypt</strong> HTTP-01-challenges.</li> Dual-stack IPv4 + IPv6</strong>.</li> HTTP/1.1, HTTP/2, HTTP/3</strong>.</li> Offentligt statisk marketing-site</strong> på Cloudflare Pages, med platform-guides i hver sin URL-sti, så de rangerer uafhængigt på Google for “netlify apex redirect”, “vercel apex domain” osv.</li> </ul> Ofte stillede spørgsmål</h2> Kan jeg bruge apextowww sammen med Cloudflare DNS?</h3> Ja — men du skal have Cloudflares proxy (den orange sky) slået fra</strong> på apex’ens A</code>/AAAA</code>-records. Hvis proxien er slået til, opfanger Cloudflare forespørgslen, og Let’s Encrypts HTTP-01-challenge når aldrig frem til apextowww. Når certifikatet er udstedt og fornyes, skal du ikke bøvle videre — bare lad det være slukket.</p> Understøtter apextowww wildcards eller andre subdomæner end www?</h3> Nej. Tjenesten omdirigerer kun apex til www.</code>. Alt andet bliver liggende hos din rigtige host.</p> Hvad sker der, hvis apextowww-IP’erne skifter?</h3> Så skal du opdatere dine DNS A</code>/AAAA</code>-records. Operatøren offentliggør aktuelle IP’er på forsiden og giver varsel før ændringer. Det er fint for et privat domæne; for noget missionkritisk bør du køre din egen omdirigerer.</p> Er der rate-limit?</h3> Der er ingen publiceret hård grænse, men det er en gratis community-tjeneste. Hvis du serverer millioner af apex-omdirigeringer i døgnet, er det tid til at selv-hoste.</p> Hvorfor ikke bare bruge Cloudflares gratis plan?</h3> Cloudflares CNAME-flattening på apex er et fint alternativ, hvis hele din DNS er hos Cloudflare. apextowww er nyttig, når din DNS ikke er hos Cloudflare, eller når du vil have en host-agnostisk omdirigerer, der virker identisk på tværs af domæner.</p> Er den virkelig gratis?</h3> Ja. Marginalomkostningen pr. omdirigering på ARM64 er minimal. Ingen reklamer, ingen tracking ud over grundlæggende logs, ingen upsell.</p> Hvorfor den findes</h2> Hostingplatforme optimerer efter deres egen onboarding, ikke efter de DNS-selvfølgeligheder, der snubler enhver ny bruger. Det føltes værre at sende folk videre til en fremmeds VPS end selv at drifte én. Nu peger mine egne apex-domæner (inklusive x2q.net</a>) på apextowww, og jeg har kunnet slukke for den sidste lille omdirigerer-VPS, jeg stadig kørte af historiske grunde.</p> Det er den slags projekt, der ikke virker interessant, før du har brug for det — og så er det lige præcis det, du skal bruge.</p>

Sådan cracker du Wi-Fi med hashcat i 2026

2026-07-03T00:00:00+00:00

Kort fortalt —</strong> airodump-ng</code> + aircrack-ng</code> + cap2hccapx</code>-pipelinen, som hver eneste tutorial fra 2015 lærer dig, er forældet. Den nuværende workflow er hcxdumptool</code></strong> til capture, hcxpcapngtool</code></strong> til at konvertere til det samlede hash mode 22000</strong>-format, og hashcat 7.1.2</code></strong> til at angribe det. Dette indlæg gennemgår hele kæden mod et WPA2-netværk, du har tilladelse til at teste, med rigtige kommandoer, realistiske 2026-GPU-hastigheder, og et ærligt svar på hvorfor intet af det virker mod WPA3-SAE.</p>

Test kun netværk du ejer eller har eksplicit skriftlig tilladelse til at teste. Se 25 år med Wi-Fi-sikkerhed</a> for den bredere historie og forsvarsvejledning, denne gennemgang supplerer.</p>

Hvad der har ændret sig siden de gamle tutorials</h2> Hvis du lærte dette fra en gammel guide, er tre ting anderledes nu:</p> hcxdumptool</code>/hcxtools</code> erstattede airodump-ng</code> + cap2hccapx</code></strong> til capture og konvertering. aircrack-ng</code> er stadig fint til at sætte et kort i monitor mode, men dets eget .cap</code>-captureformat og community-konverteren cap2hccapx</code> er legacy — de producerer kun de gamle, mere begrænsede hash modes.</li> Hash mode 22000 erstattede modes 2500 og 16800.</strong> hashcat har nu ét samlet format (WPA-PBKDF2-PMKID+EAPOL</code>), der håndterer både et PMKID-capture og et fuldt 4-vejs håndtryk-capture i samme fil.</li> PMKID først, deauth valgfrit.</strong> De fleste forbruger-APs lækker en PMKID i en enkelt frame med nul klient-interaktion — ingen deautentificering af nogen nødvendig. Deauth er nu et fallback, ikke standard-førstetrækket.</li> </ol> Krav</h2> En trådløs adapter der understøtter monitor mode og packet injection</strong> (Atheros AR9271 og Realtek RTL8812AU-chipsæt forbliver pålidelige valg i 2026).</li> hashcat 7.1.2</strong> eller nyere. hashcat -V</code> for at tjekke; projektet bevæger sig hurtigt, opdatér hvis du er bagud.</li> hcxdumptool + hcxtools</strong> (ZerBeas værktøjer) — apt install hcxdumptool hcxtools</code> på Debian/Kali, eller byg fra kilde.</li> En ordliste. Se rockyou.txt og ordlisternes nuværende tilstand</a> — start småt (rockyou-65.txt</code>), ikke med en 100 GB megaliste.</li> En GPU. hashcat kører også på CPU, men WPA’s PBKDF2-omkostningsfunktion er designet til at være langsom — en GPU er ikke valgfri, hvis du vil have resultater på rimelig tid.</li> </ul> Trin 1 — monitor mode</h2> sudo airmon-ng check kill # stop NetworkManager/wpa_supplicant der kæmper om interfacet sudo airmon-ng start wlan0 # opretter wlan0mon i monitor mode </code></pre> Eller uden aircrack-ng-pakken, med iw</code> direkte:</p> sudo ip link set wlan0 down sudo iw wlan0 set monitor control sudo ip link set wlan0 up </code></pre> Trin 2 — capture med hcxdumptool</h2> Det opportunistiske capture uden deauth — indsamler PMKID’er og håndtryk fra alt inden for rækkevidde:</p> sudo hcxdumptool -i wlan0mon -o capture.pcapng --enable_status=1 </code></pre> For at målrette et specifikt BSSID og reducere støj, byg en filterliste og send den ind:</p> echo "AA:BB:CC:DD:EE:FF" > targets.txt sudo hcxdumptool -i wlan0mon -o capture.pcapng \ --filterlist=targets.txt --filtermode=2 --enable_status=1 </code></pre> Hvis mål-AP’en ikke lækker en PMKID, og du har brug for et fuldt 4-vejs håndtryk fra en tilsluttende klient, tving en genforbindelse med et klassisk deauth (kræver tilladelse — dette påvirker klientens forbindelse):</p> sudo aireplay-ng --deauth 5 -a AA:BB:CC:DD:EE:FF wlan0mon </code></pre> Lad hcxdumptool</code> blive ved med at køre i en anden terminal, mens du gør dette — det capturer automatisk det resulterende håndtryk.</p> Trin 3 — konvertér til hash mode 22000</h2> hcxpcapngtool -o hash.22000 capture.pcapng </code></pre> Denne ene kommando udtrækker hver crackbar PMKID og EAPOL-håndtryk fundet i capturet til hashcat’s samlede format. Hvis du capturede flere netværk og vil isolere ét, filtrér den resulterende fil på BSSID (det andet felt i hver linje):</p> grep "aabbccddeeff" hash.22000 > target-only.22000 </code></pre> Trin 4 — angrib det</h2> Dictionary-angreb</h3> hashcat -m 22000 -a 0 hash.22000 rockyou-65.txt </code></pre> Start med en lille, kurateret liste, ikke den fulde 14,3M-linjers rockyou.txt</code> — se ordliste-indlægget</a> for hvorfor det nu er det bedre standardvalg.</p> Regelbaseret angreb</h3> Regler genererer muterede kandidater (case-skift, leetspeak, tilføjede cifre) fra en lille basisliste — normalt langt mere effektivt pr. sekund GPU-tid end en større umuteret liste:</p> hashcat -m 22000 -a 0 -r rules/best64.rule hash.22000 rockyou-65.txt </code></pre> Maskeangreb</h3> Nyttigt når du ved noget om PSK’ens struktur — et almindeligt standard-router-mønster (8 cifre), en PSK der ligner et telefonnummer, eller en kendt længde:</p> hashcat -m 22000 -a 3 hash.22000 ?d?d?d?d?d?d?d?d </code></pre> Combinator-angreb</h3> Sammenkæder to ordlister — nyttigt til ord+ord</code>- eller ord+tal</code>-PSK-mønstre:</p> hashcat -m 22000 -a 1 hash.22000 words.txt suffixes.txt </code></pre> Tjek resultater</h3> hashcat -m 22000 hash.22000 --show </code></pre> Realistiske hastigheder i 2026</h2> Mode 22000 kører PSK’en gennem PBKDF2-HMAC-SHA1 med 4096 iterationer</strong> — dette er med vilje, for at gøre brute-force dyrt. Det er langt fra så hurtigt som et rå hash mode som NTLM eller SHA-1.</p> GPU-klasse</th> Kandidater/sekund (mode 22000)</th> rockyou.txt</code> (14,3M) udtømt på</th></tr></thead> RTX 3090 (2022-æraen)</td> ~1,2M/s</td> ~12 s</td></tr> RTX 4090</td> ~2,5–3M/s</td> ~5 s</td></tr> RTX 5090-klasse (2025+)</td> ~5–8M/s</td> ~2–3 s</td></tr> 8× H100 cloud-instans</td> ~50M/s samlet</td> <0,3 s</td></tr> </tbody></table> Mod en tilfældig 12+-tegns PSK</strong> (entropi ≈ 2⁷²) betyder ingen af disse tal noget — udtømmende søgning tager stadig årtusinder. Mod en 8-tegns ordbogsord-PSK</strong> betyder de alle sammen en hel del.</p> Hvorfor dette ikke rører WPA3</h2> Alt ovenfor målretter WPA2’s PSK-afledte 4-vejs håndtryk</strong>, som med vilje lader en offline observatør verificere PSK-gæt mod et capturet hash. WPA3-Personal erstatter dette med SAE</strong> (Simultaneous Authentication of Equals) — en protokol specifikt bygget så et passivt capture ikke giver noget crackbart offline. Der findes ikke et hashcat-mode til “cracke WPA3-SAE offline”, fordi protokollen ikke lækker det materiale, der skal til for at prøve.</p> Den praktiske vinkel mod WPA3 i 2026 er ikke at cracke SAE — det er at finde et access point, der stadig annoncerer WPA2/3-overgangstilstand</strong>, tvinge klienten til at forhandle WPA2-siden, og køre præcis angrebet ovenfor mod det fallback. Hvis netværket er rent WPA3 med PMF (Protected Management Frames) påkrævet, har denne playbook intet at byde på. Se 25 år med Wi-Fi-sikkerhed</a> for det fulde billede, inklusive Dragonblood-downgrade-forskningen dette afhænger af.</p> Defensiv pointe</h2> Hvis du læser dette for at tjekke dit eget netværk:</p> WPA3-Personal, ingen overgangstilstand.</strong> Tjek eksplicit — mange APs falder tilbage på WPA2/3-blandet tilstand, selv når WPA3 er “aktiveret”.</li> En lang, tilfældig PSK</strong> — 20+ tegn, ikke et ordbogsord eller telefonnummer. Det er det, der faktisk stopper hvert eneste angreb ovenfor koldt, WPA2 eller WPA3.</li> Deaktivér WPS.</strong> Urelateret til hashcat, men stadig ofte efterladt tændt og stadig en langt hurtigere vej ind for en angriber.</li> PMF påkrævet, ikke valgfrit</strong>, for helt at lukke af for deauth-drevet håndtryk-capture.</li> </ul> Se også rockyou.txt og ordlisternes tilstand i 2026</a> for hvad du faktisk skal loade ind i -a 0</code>, og 25 år med Wi-Fi-sikkerhed</a> for protokolhistorien bag alt dette.</p> </blockquote> rockyou.txt: historien om verdens mest berømte ordliste (2026) 2026-07-03T00:00:00+00:00 Kort fortalt —</strong> rockyou.txt</code> er 14,3 millioner rigtige kodeord lækket i klartekst fra ét firmas databrud i 2009. Den blev standard-ordlisten for en hel generation af password cracking — bundlet i Kali Linux, citeret i hver eneste hashcat-tutorial, udødeliggjort som /usr/share/wordlists/rockyou.txt.gz</code>. I 2026 findes den stadig, men den er ikke længere det bedste værktøj til opgaven: weakpass.com’s aktuelle rangering placerer små kuraterede udsnit og løbende opdaterede ‘fundne kodeord fra virkeligheden’-lister over den. Dette indlæg dækker, hvor den kom fra, hvorfor den vandt, og hvad der reelt vinder nu.</p> December 2009: et firma der ikke hashede sine kodeord</h2> RockYou Inc.</strong> lavede Flash-baserede sociale-netværks-widgets — SuperWall, sjove foto-apps — til MySpace og Facebook, på højdepunktet af platform-app-boomet. I december 2009 eksponerede en SQL-injection</strong>-sårbarhed på RockYous side hele deres brugerdatabase: omkring 32 millioner konti</strong>.</p> Bruddet ville have været en fodnote, hvis ikke for én detalje: RockYou opbevarede kontoadgangskoder som klartekst</strong>. Ingen hashing, ingen salting — bare kodeordet, ordret, ved siden af e-mailadressen. Da dumpet cirkulerede, havde sikkerhedsforskere noget nærmest uhørt: millioner af rigtige kodeord, i klartekst</strong>, uden behov for cracking for at se, hvad folk faktisk valgte.</p> Efter fjernelse af dubletter endte den unikke kodeord-kolonne på ~14,3–14,4 millioner linjer</strong>, og den begyndte at cirkulere som en almindelig .txt</code>-fil under navnet på det brudte firma: rockyou.txt</code>.</p> Hvorfor den blev standarden</h2> Der skete masser af lækager før og efter 2009. rockyou.txt</code> blev specifikt standarden for pentest/CTF/red-team af nogle konkrete grunde:</p> Det var rigtige, uhashede, menneskevalgte data.</strong> Ikke en ordbog af engelske ord, ikke et genereret permutationssæt — rigtige kodeord rigtige mennesker skrev, med bias mod præcis den slags forudsigelige mønstre (iloveyou</code>, password1</code>, fødselsdatoer, tastatur-walks), som rigtige konti kompromitteres med.</li> Størrelsen passede til hardwaren fra tiden.</strong> 14,3M kandidater kørte til ende på en enkelt CPU eller tidlig GPU på rimelig tid — nyttig, ikke bare symbolsk.</li> Den var gratis og overalt.</strong> Ingen konto-mur, ingen nedtagning der holdt. Den blev bundlet i SecLists</strong> og leveret som standard i BackTrack</strong>, derefter Kali Linux</strong>, på /usr/share/wordlists/rockyou.txt.gz</code> — hvilket satte den på hver eneste pentesters maskine, uanset om de ledte efter den eller ej.</li> Engelsk-flertals-bias matchede flertallet af tidlige 2010’er-mål.</strong> Efterhånden som cracking-værktøjer blev globale, blev dette en begrænsning, ikke bare en fordel — men på det tidspunkt var det en hitrate-fordel.</li> </ul> I begyndelsen af 2010’erne var “kør rockyou.txt mod det” standardtrækket i næsten hvert eneste WPA-håndtryk, hashet database-dump eller CTF-udfordring med et kodeord-hash.</p> Navnet overlevede bruddet</h2> Her er den del, der overrasker folk: rockyou2021.txt</strong> og rockyou2024.txt</strong>, de kæmpestore efterfølger-navngivne lister du finder i dag, er ikke</strong> nye brud på RockYou Inc.</p> rockyou2021.txt</strong> dukkede op på et hacker-forum i juni 2021: omkring 8,46 milliarder linjer</strong>, sammensat ved at flette dusinvis af tidligere lækager, ordlister og algoritmisk genererede permutationer (case-varianter, leetspeak-substitutioner, tal-suffikser) — ikke friskstjålne credentials.</li> rockyou2024.txt</strong> fulgte samme mønster i 2024: omkring 9,95 milliarder linjer</strong>, endnu en community-megasammensætning.</li> </ul> Navnet “rockyou” blev genbrugt som et brand for “den største sammensatte cracking-ordbog lige nu”</strong>, løsrevet fra sin oprindelige betydning. Begge er rigtige, begge er enorme, og begge er værd at have — men ingen af dem fortæller dig noget om RockYou Inc.’s faktiske 2009-brugere. Behandl navnet som en genre-etiket, ikke en oprindelsespåstand.</p> Hvad weakpass.com’s rangering faktisk viser i 2026</h2> weakpass.com</a> er det tætteste, cracking-communityet har på et live ordliste-leaderboard: hundredvis af lister, hver med størrelse, antal linjer og en bogstavkarakter for effektivitet (S til F)</strong> — baseret på reel cracking-hitrate, ikke rå størrelse. At trække den aktuelle top af tavlen er mere interessant end noget enkelt tal:</p> Ordliste</th> Rang</th> Størrelse</th> Linjer</th></tr></thead> weakpass_4.merged.txt</code></td> S</td> 37,72 GB</td> 3,58 mia.</td></tr> all-h.txt</code></td> S</td> 28,51 GB</td> 2,72 mia.</td></tr> all-h.latin.txt</code></td> S</td> 28,35 GB</td> 2,71 mia.</td></tr> triple-h.txt</code></td> S</td> 21,82 GB</td> 2,13 mia.</td></tr> SAWL.txt</code></td> S</td> 17,02 GB</td> 1,49 mia.</td></tr> cyclone.hashesorg.hashkiller.combined.txt</code></td> S</td> 15,02 GB</td> 1,47 mia.</td></tr> hashpwn.txt</code></td> S</td> 14,11 GB</td> 1,35 mia.</td></tr> Hashes.org</code></td> S</td> 13,99 GB</td> 1,40 mia.</td></tr> dictionary_private.dic</code></td> S</td> 2,66 GB</td> 206,28 mio.</td></tr> hashmob.net_2025.user.found</code></td> S</td> 979,96 MB</td> 84,29 mio.</td></tr> rockyou-65.txt</code></td> S</td> 238,80 KB</td> 30,29 K</td></tr> weakpass_4a.txt</code></td> A</td> 81,37 GB</td> 8,44 mia.</td></tr> clatsdictionary.txt</code></td> A</td> 71,55 GB</td> 7,87 mia.</td></tr> rockyou2024.txt</code></td> B</td> 145,27 GB</td> 9,95 mia.</td></tr> rockyou2021.txt</code></td> B</td> 91,62 GB</td> 8,46 mia.</td></tr> rockyou.txt</code> (originalen)</strong></td> C</strong></td> 133,44 MB</strong></td> 14,34 mio.</strong></td></tr> </tbody></table> Den sidste række er den interessante. Den originale rockyou.txt</code> — filen der definerede et årti af tutorials — rangerer under</strong> både et 238-kilobyte kuraterede udsnit af sig selv og de milliard-linjers megasammensætninger, der lånte dens navn. Tre ting sker på samme tid:</p> 1. Rang måler hitrate, ikke størrelse</h3> weakpass bedømmer efter cracking-effektivitet</strong>, ikke rå antal linjer. En lille, omhyggeligt kurateret liste, der rammer en høj procentdel af rigtige kodeord pr. forsøgt kandidat, rangerer over en vidtstrakt liste polstret med permutationsstøj. Derfor sidder rockyou-65.txt</code> — et udsnit på 30.290 linjer, 238 KB</strong> — i S-klasse</strong>, samme kategori som 30+ GB megalister, mens originalen med 14,34 millioner linjer sidder tre klasser lavere.</p> 2. Procentvis udsnit af rockyou er en reel teknik</h3> weakpass udgiver en hel familie af rockyou-XX.txt</code>-filer — rockyou-5.txt</code> op til rockyou-75.txt</code> — hver et sandsynlighedsvægtet udsnit af originalen, holdt i faldende rækkefølge efter observeret hyppighed. rockyou-5.txt</code> er 13 linjer; rockyou-75.txt</code> er 59.190. Ideen: til en hurtig første gennemgang mod et stort sæt hashes udgør de øverste 5–15% af rockyou.txt</code> efter observeret hyppighed ofte en uforholdsmæssig stor andel af de crackbare konti. Prøv det lille udsnit først; grib kun til den fulde 14,3M-linjers liste, eller efterfølgerne på milliarder af linjer, hvis det hurtige gennemløb kommer tomhændet tilbage.</p> Udsnit</th> Størrelse</th> Linjer</th></tr></thead> rockyou-5.txt</code></td> 104 Bytes</td> 13</td></tr> rockyou-25.txt</code></td> 7,06 KB</td> 929</td></tr> rockyou-50.txt</code></td> 74,13 KB</td> 9,44 K</td></tr> rockyou-65.txt</code></td> 238,80 KB</td> 30,29 K</td></tr> rockyou-75.txt</code></td> 467,72 KB</td> 59,19 K</td></tr> rockyou.txt</code> (fuld)</td> 133,44 MB</td> 14,34 mio.</td></tr> </tbody></table> 3. “Fundet i naturen, i år” slår “lækket engang, for et årti siden”</h3> Det andet mønster i toppen af S-klassen: hashmob.net_2025..found</code></strong>-listerne. hashmob.net</a> er et levende community-hub for hash-cracking — kodeord-hashes bliver indsendt, communityet cracker hvad det kan, og de succesfuldt crackede klartekster udgives tilbage som ordlister, løbende opdateret. Fordi de repræsenterer kodeord folk vælger lige nu</strong>, ikke kodeord folk valgte i 2009, har de en aktualitetsfordel, ingen statisk lækage kan matche, uanset størrelse.</p> Hvad det betyder i praksis</h2> Hvis du vælger en ordliste i 2026, er “største fil” den forkerte tommelfingerregel:</p> Start småt og målrettet.</strong> Et kurateret udsnit (rockyou-65.txt</code>) eller en frisk “fundet”-liste slår en 100 GB megafil til en første gennemgang — det er færdigt på sekunder og rydder ofte en meningsfuld del af de svage konti.</li> Tilføj regler før størrelse.</strong> hashcat -a 0 -r best64.rule</code> (eller den langt større OneRuleToRuleThemAll.rule</code>) mod en beskeden basisliste genererer størrelsesordener flere effektive kandidater end den samme liste kørt rå — og slår normalt en større umuteret liste for samme tidsbudget.</li> Grib til megalisterne til sidst.</strong> rockyou2021.txt</code>, rockyou2024.txt</code>, weakpass_4.merged.txt</code> og lignende er værd at have til udtømmende offline-arbejde mod et hash-sæt, du har råd til timer eller dage imod — ikke som det første, du prøver.</li> Den originale rockyou.txt</code> er stadig en fin baseline</strong> — gratis, lille nok til hurtig iteration, velforstået — bare ikke længere loftet.</li> </ol> Se hashcat WiFi-cracking i 2026</a> for disse ordlister i aktion mod et rigtigt WPA-håndtryk, og 25 år med Wi-Fi-sikkerhed</a> for den bredere angrebs- og forsvarshistorie.</p> </blockquote> Fine-tuning af Whisper til danske telefonopkald: en LoRA-obduktion (2026) 2026-07-02T00:00:00+00:00 Kort fortalt —</strong> Fine-tunede whisper-large-v3</a> på CoRal-project/coral-v3</a> (rigtig, menneske-transskriberet dansk tale) med en LoRA-adapter, telefon-kodek-augmenteret for at lukke hullet til rigtig telefonlyd. Træningstabet sad fast på samme plateau tre gange i træk</strong>, og hver gang så forklaringen anderledes ud — indtil det viste sig at være én kedelig skemalægningsfejl. Rettet, og modellen halverede næsten word error rate</strong> på tilbageholdt dansk tale. Så fandt en systematisk gennemgang af rigtige telefonoptagelser, at benchmark-tallet ikke fortalte hele historien. Udgivet alligevel — på Hugging Face</a>, med et ærligt modelkort.</p> Fine-tuning-efterfølgeren til transskribering af 33.000 danske voicelogs på hjemme-GPU’er</a>. Det indlæg valgte basismodellerne; dette forsøger at gøre en af dem bedre.</p> </blockquote> Tabet, der ikke ville bevæge sig</h2> Opsætningen: PEFT</a> LoRA (rank 32, alpha 64, q_proj</code>/v_proj</code>) oven på whisper-large-v3, trænet på ~9.000 lydstykker fra coral-v3 — tre fjerdedele kørt gennem en telefon-kodek-simulering (8kHz-båndbreddegrænse, lav-bitrate-mp3-rundtur, let støj), så modellen ville se noget tættere på rigtig opkaldslyd end coral-v3’s rene studieoptagelser.</p> Krydsentropi-tab bør starte højt og falde til enkeltcifrede tal, efterhånden som træningen konvergerer. I stedet gjorde tre separate forsøg det samme: et skarpt indledende fald, derefter et hårdt plateau omkring 35-40, der aldrig bevægede sig, uanset hvor længe træningen kørte. Hvert forsøg pegede på en anden synder — og hver rettelse var reel, og ingen af dem løste det faktiske problem:</p> Mistænkt: dårlig lyd.</strong> Coral-v3’s rå optagelser viste sig at have vildt uensartede lydstyrker — nogle stykker praktisk talt næsten stille (median-RMS en størrelsesorden under sund tale). Whispers feature-extractor er følsom over for absolut amplitude, så dette var en reel fejl. Rettet med lydstyrkenormalisering (EBU R128, -16 LUFS) på hvert stykke. Tabet: sad stadig fast på 35-40.</strong></li> Mistænkt: dobbeltbehandling.</strong> Træningsscriptet genanvendte et støj-/EQ-filter beregnet til rå, ubehandlet</em> produktionslyd på data, der allerede var fuldt forbehandlet — en rest fra genbrug af kode skrevet til en anden datakilde. Bekræftet ved direkte måling: det overflødige filter pressede nogle stykkers lydstyrke lige tilbage ned. Rettet. Tabet: sad stadig fast på 35-40.</strong></li> Mistænkt: modellen selv.</strong> Med begge lydfejl rettet og plateauet uændret, skiftede arbejdsteorien til, at læringsraten var ustabil for den fulde</em> whisper-large-v3 (32 decoder-lag) versus den mindre turbo-variant (4 lag), som en tidligere, vellykket fine-tuning havde brugt. En kontrolleret test — samme LoRA-konfiguration, samme kendt-gode data, kun basismodellen udskiftet — genskabte det identiske plateau. Test af en 5x lavere læringsrate gav et identisk</em> resultat. Det var beviset: to forskellige læringsrater, der konvergerer til præcis den samme “fastsiddende” værdi, er ikke et læringsrate-problem.</strong></li> Den faktiske fejl.</strong> Warmup-skemaet var 100 skridt, og hvert testkørsel — inklusive, viste det sig, de rigtige</em> træningskørsler — blev kun nogensinde observeret midtvejs gennem den optrapning. Læringsrate-skemalæggeren klatrede stadig mod sin målværdi hele tiden, nogen havde kigget på den. Et kort, proportionalt warmup (40 af 548 samlede skridt) konvergerede rent i det allerførste efterfølgende forsøg: 98 → 83 → 68 → 54 → 39 → 26 → 16 → 13 → 11 → 9,5</strong>, der fulgte næsten præcis banen for en tidligere, allerede bevist fine-tuning.</li> </ol> To af de tre rettelser var reelle fejl, det var værd at rette i sig selv. Ingen af dem var den</em> fejl. Lektionen generaliserer ud over dette ene projekt: en metrik, der ser “fastsiddende” ud, kan bare være et skema, der ikke er færdigt med at trappe op</strong> — tjek det, før du konkluderer, at noget grundlæggende er i stykker.</p> (En mindre, separat fejl undervejs: parallelisering af data-forberedelsestrinnet med en trådpulje gav nondeterministiske nedbrud med en PyGILState_Release</code>-fejl — et C-udvidelses-trådproblem, ikke min kodes logik. En procespulje, som giver hver worker sin egen uafhængige interpreter-tilstand, løste det fuldstændigt. Foretræk procespuljer frem for trådpuljer, når arbejdet er C-udvidelsestungt</strong> (lydafkodning, kodek-kald) frem for ren Python.)</p> Benchmarket: en reel gevinst</h2> Med træning, der rent faktisk konvergerede, den rigtige test: et tilbageholdt sæt coral-v3-stykker (adskilt fra træningen — garanteret ved at springe det nøjagtige antal stykker over, som træningen brugte, fra den samme deterministiske blanding) med rigtig ground truth, så word error rate kan beregnes direkte i stedet for at blive vurderet med øjemål.</p> model</th> samtale-dansk WER</th> oplæsnings-dansk WER</th></tr></thead> whisper-large-v3 (utrænet)</td> 0,704</td> 0,303</td></tr> fine-tunet (dette indlæg)</strong></td> 0,367</strong></td> 0,220</td></tr> CoRals egen formålsbyggede danske model</td> 0,327</td> 0,101</td></tr> </tbody></table> Næsten en halvering</strong> af samtale-WER fra en generisk basismodel, der lukker det meste af hullet til en model bygget fra bunden til dansk. Oplæsningstallet forbedredes mindre, fordi træningen kun brugte coral-v3’s conversation</code>-split — en klar, testbar forudsigelse, der holdt stik (formel, skriptet tale er en anden fordeling end uformel samtale, og modellen så kun den ene af dem).</p> Men WER var ikke hele historien</h2> Et WER-tal er en samlet størrelse: det fortæller dig hvor meget</em> tekst der afviger fra referencen, ikke hvilken slags</em> fejl der er tale om. En model, der af og til erstatter et rigtigt ord med et andet, forkert-men-plausibelt ord, og en model, der af og til finder på en selvsikker, flydende, helt fabrikeret sætning, kan opnå den samme</em> WER — men kun den ene af dem er sikker at bruge uden opsyn.</p> Så: en systematisk kvalitativ gennemgang, på rigtige (ikke benchmark-) telefonoptagelser — det faktiske måldomæne, ikke en stedfortræder for det. Hvert output fra den fine-tunede model blev sammenlignet med fem andre modellers transskriptioner af den samme lyd, specifikt på udkig efter indhold uden opbakning noget andet sted: et opdigtet navn, en opdigtet detalje, en påstand der ikke blev sagt. (Intet opkaldsindhold gengives her — optagelserne er private forretningsopkald; kun det samlede resultat betyder noget for dette indlæg.)</p> Resultatet: omtrent hvert ottende opkald viste en klar fabrikation</strong> — indhold sagt med selvsikkerhed, som ingen anden model, og formodentlig ingen på opkaldet, rent faktisk sagde. Omkring halvdelen af opkaldene var i praksis ækvivalente med den utrænede baseline, og det meste af resten adskilte sig kun i formulering eller udeladelse, ikke opdigtning. Et genuint interessant sidespring: den utrænede basismodel</em> har sin egen velkendte fejltilstand på stille lyd (en specifik hallucineret “falsk undertekst-credit”-linje, en dokumenteret Whisper-artefakt), der dukkede op på en sammenlignelig andel af opkald — og den fine-tunede model genskabte aldrig den specifikke fejl, hvilket tyder på, at fine-tuningen byttede én fejlklasse ud med en anden i stedet for blot at lægge et nyt problem oven på en ren baseline.</p> Samlet vurdering:</strong> en reel, betydelig nøjagtighedsforbedring på den metrik, der er let at måle, og et reelt, ikke-trivielt pålidelighedshul på den egenskab, der rent faktisk betyder noget for brug uden opsyn — opdigtede navne og enheder er præcis det forkerte at få galt i et system, der bruges til at spore, hvem der sagde hvad. Ingen af de to kendsgerninger ophæver den anden.</p> Udgivet alligevel</h2> Adapteren er på Hugging Face: x2q/whisper-large-v3-da-coral-lora</a></strong>. Modelkortet angiver WER-tallene, træningsdata og licens (coral-v3 er OpenRAIL-licenseret og citeret direkte — ingen grund til at skjule et legitimt, statsstøttet dansk tale-datasæt bag en vagere beskrivelse), fabrikationsrate-fundet, og en konkret brugsadvarsel: brug den ikke som eneste kilde til automatisk navne-/enhedsudtræk uden en anden model eller et menneske i løkken.</p> En mangelfuld model med et ærligt kort er mere værd for den, der finder den, end en tavs én.</p> Lektionerne, destilleret</h2> En fastsiddende metrik kan bare være et ufærdigt skema</strong> — tre plausibelt lydende grundårsager (dårlig data, dobbeltbehandling, læringsrate-ustabilitet) var alle reelle fejl og alle forkerte om den faktiske årsag, som var en warmup-optrapning, ingen havde ladet færdiggøre, før de drog konklusioner.</li> To forskellige værdier, der konvergerer til det identiske forkerte svar, er et stærkt signal</strong> — hvis ændring af en hyperparameter ikke ændrer resultatet, er hyperparameteren sandsynligvis ikke årsagen.</li> Procespuljer frem for trådpuljer til C-udvidelsestungt parallelt arbejde</strong> — et nondeterministisk nedbrud på interpreter-niveau forsvandt fuldstændigt, da hver worker fik sin egen proces i stedet for at dele én interpreters GIL-tilstand.</li> En enkelt samlet metrik kan ikke se fejltilstands-diversitet</strong> — WER behandler et forvansket ord og en selvsikkert opdigtet sætning ens. Hvis de to betyder noget forskelligt for dit brug (det gør de næsten altid), har du brug for en kvalitativ gennemlæsning, ikke bare et bedre tal.</li> Udgiv fejlen, ikke kun gevinsten</strong> — en dokumenteret fejlrate med klar brugsvejledning er et mere nyttigt artefakt end et pænt udseende modelkort, der viser sig at skjule det samme problem, basismodellen allerede havde.</li> </ol> Fem alternativer til pyannote: speaker diarization til telefonopkald (2026) 2026-06-24T00:00:00+00:00 Speaker diarization — at afgøre “hvem talte hvornår” — lyder simpelt og viser sig at være svært. Dette indlæg dokumenterer et weekendeksperiment med fem alternative tilgange til min nuværende produktionspipeline.</p> Baggrund</h2> Jeg optager og transskriberer alle mine erhvervsopkald automatisk. Pipelinen er groft sagt:</p> Opkald ankommer, audio gemmes som MP3</li> Whisper</a> transskriberer til ordniveausegmenter</li> Et diarization-trin tildeler hvert segment en taler</li> Alt lander i en SQLite-database med et Markdown-resumé</li> </ol> Trin 3 er det interessante. Jeg landede på pyannote/speaker-diarization-3.1</strong> som produktionsbackend efter at tidligere eksperimenter udelukkede NeMo MSDD, reference-guided ECAPA og DiarizationLM. Pyannote virker pålideligt — men den bruger 4–5 sekunder pr. opkald og kræver en Hugging Face-token med accepterede modelvilkår. Jeg ville vide, om nyere forskning har produceret noget meningsfuldt bedre.</p> Benchmark</h2> 8 rigtige opkald, 288–592 sekunder, alle 2-partssamtaler.</strong> Jeg kører hvert alternativ mod pyannotes output og måler segment-level agreement</em>: andelen af Whisper-segmenter, hvor alternativet tildeler samme speaker-label som pyannote, under den bedste permutationsmapping.</p> Dette måler lighed med pyannote</em>, ikke absolut korrekthed. En metode der afviger fra pyannote kan faktisk have mere</em> ret — der er ingen human ground truth at sammenligne med. Husk det, når du læser tallene.</p> Alle fem bruger pyannotes interne WeSpeaker ResNet34-LM</strong> embedding-model (256-dim, cosine, trænet på VoxCeleb) — samme model pyannote bruger internt, så den er allerede indlæst.</p> Baseline — EXP E (udgik tidligt)</h2> Inden F–J prøvede jeg at bygge taler-referencer fra pyannotes egne labels i databasen og køre WeSpeaker nearest-neighbour mod dem. Den nåede 88 % agreement — men er cirkulær: den bruger pyannotes labels som input. Ubrugelig som erstatning.</p> EXP F — WeSpeaker + Spectral Clustering</h2> Idé:</strong> SpectralClustering med normaliseret cosine-affinitet slår AgglomerativeClustering på 2-taler-opgaver (Park et al. ICASSP 2022; Landini et al. IS 2022). Den globale grafstruktur slår grådige lokale sammensætninger.</p> Flow:</strong></p> Gruppér Whisper-segmenter i turns (< 0,5 s pause = samme turn)</li> Embed hvert turn med WeSpeaker ResNet34 (256-dim, L2-normaliseret)</li> Byg cosine-affinitetsmatrix, kør SpectralClustering(n_clusters=2)</code></li> Map klyngerne til navne via opkaldsretning</li> </ol> Tid:</strong> ~0,2 s — 25× hurtigere end pyannote.</p> EXP G — Multi-scale WeSpeaker + AHC</h2> Idé:</strong> Korte turns giver ustabile embeddings. Løs det ved at embedde hvert turn i tre vinduesstørrelser — 0,5×, 1× og 2× turn-varighed centreret om turn-midten — og middel de tre embeddings. Inspireret af NeMos MSDD-arkitektur (Kwon et al. 2022).</p> Flow:</strong> Samme som F, men brug det middelte multi-scale embedding. Clustering med AgglomerativeClustering (cosine</code>, average</code> linkage).</p> Tid:</strong> ~0,6 s.</p> EXP H — WeSpeaker + PLDA + Spectral Clustering</h2> Idé:</strong> PLDA (Probabilistic Linear Discriminant Analysis) modellerer within- og between-speaker-kovarians og slår konsistent cosine-distance til speaker clustering (Snyder et al. 2018; dominerende i VoxSRC 2023-vindersystemer).</p> pyannote-audio</code>-pakken medfølger et trænet PLDA-objekt med LDA-transformationen _xvec_tf</code> og egenværdierne phi</code>.</p> Flow:</strong></p> LDA-projektion: mat_lda = plda._xvec_tf(embeddings)</code> — reducerer 256 → 128 dim</li> Pairwise Simplified-PLDA log-likelihood ratio: φ</code> = PLDA-egenværdier (plda.phi</code>, 128-dim)</li> w_same = φ / (φ + 2)</code> — vægt for at x og y er samme taler</li> w_diff = 1 / (φ + 1)</code> — straf for at de er forskellige</li> LLR(x, y) = Σ [ w_same·(xᵢ+yᵢ)²/2 − w_diff·(xᵢ²+yᵢ²)/2 ]</code></li> </ul> </li> Konvertér til affinitet: A = 1 / (1 + exp(−LLR))</code></li> SpectralClustering(n_clusters=2, affinity="precomputed")</code></li> </ol> Tid:</strong> ~0,3 s.</p> EXP I — Silero VAD + WeSpeaker + Spectral Clustering</h2> Idé:</strong> Whisper-segmentgrænser er semantiske, ikke akustiske — de følger meningen, ikke mundens åbning. Bedre VAD-grænser giver renere embeddings. VBx-systemet (Landini et al. Odyssey 2022) viser, at nær-oracle VAD er kritisk for embedding-kvalitet. Silero VAD (Silero Team 2021) kører på CPU og bruger ~1 ms pr. sekund audio.</p> Flow:</strong></p> Kør Silero VAD på rå audio (threshold=0.4</code>, min_speech=250 ms</code>, min_silence=300 ms</code>)</li> Gruppér Silero-timestamps i turns (< 0,5 s pause)</li> Embed hvert Silero-turn med WeSpeaker</li> Map Whisper-segmenter til nærmeste Silero-turn via tidsoverlap</li> SpectralClustering(n_clusters=2)</code></li> </ol> Tid:</strong> ~2,1 s (domineret af Silero på CPU).</p> EXP J — Cross-call speaker gallery (nearest-neighbour)</h2> Idé:</strong> Ingen clustering overhovedet. Byg i stedet et galleri af kendte talere fra historiske kald i databasen, og klassificér nye turns med cosine nearest-neighbour — som i speaker-recognition-litteraturen (Ding et al. ICASSP 2020; x-vector NN-baseline i VoxSRC 2021–2023).</p> Flow:</strong></p> Hent de seneste 40 færdigbehandlede kald fra DB</li> Sample op til 8 WeSpeaker-embeddings pr. taler pr. kald → {taler: [emb, ...]}</code></li> Beregn middelembedinget pr. taler, L2-normaliser</li> For hvert nyt turn: find galleri-taleren med højeste cosine-similaritet</li> Snap til linje-ejer eller modpart baseret på opkaldsretning</li> </ol> Tid:</strong> ~0,2 s ekskl. gallery-opbygning (12 s én gang ved opstart, derefter cached).</p> Resultater — 8 opkald</h2> Opkald</th> Varighed</th> Pyannote-fordeling</th> F SC</th> G MS</th> H PLDA</th> I Silero</th> J Gallery</th></tr></thead> Kald A</td> 308 s</td> 68 / 34 seg.</td> 66,7 %</td> 65,7 %</td> 88,2 %</strong></td> 88,2 %</strong></td> 69,6 %</td></tr> Kald B</td> 288 s</td> mono</strong> (10/0)</td> 80,0 %</td> 90,0 %</td> 80,0 %</td> 90,0 %</td> 80,0 %</td></tr> Kald C</td> 320 s</td> 4 / 33 seg.</td> 75,7 %</td> 86,5 %</strong></td> 78,4 %</td> 81,1 %</td> 75,7 %</td></tr> Kald D</td> 314 s</td> mono</strong> (99/0)</td> 35,4 %</td> 1,0 %</td> 35,4 %</td> 61,6 %</td> 47,5 %</td></tr> Kald E</td> 384 s</td> 20 / 39 seg.</td> 62,7 %</td> 64,4 %</td> 66,1 %</td> 74,6 %</strong></td> 69,5 %</td></tr> Kald F</td> 393 s</td> mono</strong> (84/0)</td> 40,5 %</td> 1,2 %</td> 10,7 %</td> 48,8 %</td> 47,6 %</td></tr> Kald G</td> 401 s</td> 63 / 90 seg.</td> 58,8 %</td> 59,5 %</td> 57,5 %</td> 88,9 %</strong></td> 62,1 %</td></tr> Kald H</td> 592 s</td> 43 / 64 seg.</td> 71,0 %</td> 58,9 %</td> 70,1 %</td> 75,7 %</strong></td> 64,5 %</td></tr> Gennemsnit</strong></td> </td> </td> 61,3 % ±15 %</td> 53,4 % ±32 %</td> 60,8 % ±24 %</td> 76,1 % ±14 %</strong></td> 64,6 % ±11 %</td></tr> </tbody></table> Pyannote-referencetid: 5,1 s</strong> gennemsnit pr. opkald.</p> Kald B, D og F er “mono” — én part dominerer næsten 100 % af segmenterne. Disse er de sværeste cases.</em></p> Tre overraskelser</h2> 1. EXP G kollapsede fuldstændigt på mono-kald</h3> 1,0 % og 1,2 % agreement. Det er ikke bare dårligt — det er aktivt forkert. AHC med n_clusters=2</code> tvinger to klynger uanset hvad: på mono-kald ender den med én kæmpe klynge og én med nærmest ingen segmenter, og den globale label-swap-permutation redder det ikke. Multi-scale hjalp intet.</p> Spectral Clustering (F, H, I) er lidt mere robust — 35–61 % på de samme kald — men kollapsede stadig. Ingen af de fem tilgange ved</em> at der kun er én taler.</p> 2. PLDA — 88 % på rigtige 2-taler-kald, 10 % på mono</h3> PLDA-metoden (H) klarede sig bedst på kald med to tydeligt adskilte talere. Det er præcis hvad PLDA er designet til: at modellere forskellen i embedding-rummet mellem to taler-distributioner. Men på mono-kald splitter den alligevel, og ender med en worst-case på 10,7 %.</p> 3. Gallery-metoden var den mest stabile (±11 %)</h3> EXP J vandt ikke i gennemsnit, men havde langt laveste varians. Den “ved” hvem linje-ejeren er fra historiske kald og gætter rimeligt på modparten. Fejler systematisk på talere den aldrig har hørt — første gang en ny kontakt ringer er gallery-embeddinget tomt for den person.</p> Konklusion</h2> Vandt: EXP I (Silero VAD + WeSpeaker + SC)</strong> — 76,1 % agreement, 2,4× hurtigere end pyannote (2,1 s mod 5,1 s).</p> Forklaringen er at Sileros akustiske VAD-grænser giver renere turn-segmenter end Whispers semantiske grænser. Whisper skærer, hvor meningen stopper; Silero skærer, hvor munden stopper. Renere segmenter → renere embeddings → bedre clustering.</p> Forblev på pyannote 3.1 i produktion.</strong> Alle fem alternativer fejler på mono-kald, og mono-kald er et reelt scenarie i en produktionspipeline. Nær-ensidigt kald, mistet forbindelse, kort bekræftende svar — ingen af dem håndteres korrekt af klyngemetoder med fast n_clusters=2</code>.</p> Den mest lovende sti fremad: EXP I + 1-taler-detektor.</strong> Beregn cosine-variansen inden for en turns embeddings; er variansen under en grænseværdi, er opkaldet sandsynligvis mono og alle segmenter tildeles linje-ejeren. Det ville sandsynligvis nå 85–90 % agreement ved ~2,5 s total — sammenlignelig med pyannote på rigtige 2-taler-kald og korrekt på mono-kald.</p> Se den fulde pipeline</a> og Whisper backend-benchmarks</a> for den bredere kontekst dette eksperiment lever i.</p> </blockquote> Apple M1 Pro vs RTX 4070 Ti til lokal AI — GPU-matmul og LLM-benchmarks (2026) 2026-06-22T00:00:00+00:00 Kort fortalt —</strong> En 4096×4096 float16 matrixmultiplikation afslører et 18× rå beregningsgab</strong>: RTX 4070 Ti rammer 75 TFLOPS via tensor cores; M1 Pro MPS når 4,2 TFLOPS. Men kør en rigtig LLM, og gabet kollapser til 3–4×</strong> — fordi tokengenerering ved batch størrelse 1 er hukommelsesbåndbredde-begrænset, ikke beregnings-begrænset. Begge maskiner kan køre nyttige modeller lokalt; de bytter på VRAM-loft vs hastighed.</p> Ledsager til Rust vs Go vs C på de samme maskiner</a> — samme hardware, anderledes spørgsmål.</p> </blockquote> Opsætning</h2> </th> M1 Pro (Metal/MPS)</th> RTX 4070 Ti (CUDA)</th></tr></thead> Maskine</strong></td> Apple MacBook Pro</td> Desktop-PC</td></tr> GPU</strong></td> M1 Pro 16-kerne GPU</td> NVIDIA GeForce RTX 4070 Ti</td></tr> VRAM / GPU-mem</strong></td> 16 GB unified (delt med CPU)</td> 12 GB GDDR6X</td></tr> CPU</strong></td> M1 Pro, 8-kerne (6P+2E)</td> Intel i5-13400F, 16 tråde</td></tr> RAM</strong></td> 16 GB</td> 125 GB</td></tr> OS</strong></td> macOS 26.6</td> Ubuntu 24.04, CUDA 12.1, driver 595</td></tr> PyTorch</strong></td> 2.7.0, MPS-backend</td> 2.5.1+cu121</td></tr> ollama</strong></td> 0.30.8</td> 0.30.8</td></tr> </tbody></table> Benchmark 1 — GPU-matrixmultiplikation (rå TFLOPS)</h2> En enkelt 4096×4096 tæt matmul, 20 tids-kørsler efter 5 opvarmningskørsler. Synkroniseret før og efter for at ekskludere kernel launch overhead. Dette er en proxy for rå tensor-beregningsgennemstrømning</strong> — loftet alt andet løber imod.</p> Enhed</th> dtype</th> ms / kørsel</th> TFLOPS</th></tr></thead> i5-13400F CPU</td> float32</td> 237,8 ms</td> 0,58</td></tr> M1 Pro CPU</td> float32</td> 86,4 ms</td> 1,59</td></tr> M1 Pro MPS</td> float32</td> 35,8 ms</td> 3,84</td></tr> M1 Pro MPS</td> float16</td> 33,0 ms</td> 4,16</td></tr> RTX 4070 Ti CUDA</td> float32</td> 4,9 ms</td> 28,3</td></tr> RTX 4070 Ti CUDA</td> float16</td> 1,8 ms</strong></td> 75,3</strong></td></tr> RTX 4070 Ti CUDA</td> bfloat16</td> 1,8 ms</td> 74,9</td></tr> </tbody></table> Hvad tallene betyder</h3> M1 Pro MPS float16 → float32 adskiller sig knap (4,16 vs 3,84 TFLOPS).</strong> M1 GPU’en har ikke dedikerede fp16 tensor cores som NVIDIA. Begge præcisioner kører igennem den samme hardware; fp16-stien sparer noget hukommelsesbåndbredde men vinder lidt beregning.</p> RTX 4070 Ti float16 → 75 TFLOPS — et 18× spring over M1 og et 2,7× spring over sin egen float32.</strong> Dette er tensor core-effekten. NVIDIAs Ada Lovelace-generation (RTX 40xx) har 4. generation tensor cores der opererer nativt på fp16/bf16 matrix-felter og når ca. 4× gennemstrømningen af fp32 CUDA-kernerne på den samme chip. PyTorch router torch.float16</code> matmul igennem dem automatisk.</p> M1 Pro CPU slår Intel i5-13400F CPU med 2,7×</strong> trods begge med 8 aktive tråde. M1 bruger AMX (Apple Matrix Extensions)</strong> — dedikerede matrix-multiplikationsenheder i hver CPU-kerne, separate fra NEON SIMD. PyTorches macOS-backend router float32-matmul igennem dem automatisk. Intel i5’en bruger AVX2 (256-bit SIMD ombrugt til matmul), som er generel brug og markant mindre effektivt til tæt matrixarbejde.</p> Benchmark 2 — LLM-inferens (tokens / sekund, ollama)</h2> Fast 300-token genereringsopgave, temperatur=0, målt som eval_count / eval_duration</code> fra ollama API-svaret (ekskluderer prompt-eval-tid, som rapporteres separat). Prompten beder om en detaljeret forklaring af transformer-internals for at sikre at modellen genererer tæt, varieret output.</p> Model</th> Størrelse</th> M1 Pro tok/s</th> RTX 4070 Ti tok/s</th> RTX / M1</th></tr></thead> minicpm-v4.6</td> 1,6 GB</td> 95,3</td> 278,9</td> 2,9×</strong></td></tr> qwen3.5</td> 6,6 GB</td> 20,3</td> 73,5</td> 3,6×</strong></td></tr> gemma4:12b</td> 7,6 GB</td> —</td> 49,1</td> —</td></tr> </tbody></table> Prompt-eval (tid til første token): M1 Pro 25ms / 115ms; RTX 4070 Ti 9ms / 22ms / 42ms for de tre modeller.</em></p> Båndbredde-historien</h3> Rå beregningsgabet er 18×. LLM-gennemstrømningsgabet er kun 3–4×. Hvorfor?</p> LLM-dekodning ved batch=1 er hukommelsesbåndbredde-begrænset, ikke beregnings-begrænset.</strong> Hvert genereret token kræver at indlæse hele sættet af modelvægte fra VRAM (eller unified memory) én gang per forward pass. Beregningen per byte er lav. GPU’en bruger næsten al sin tid på at flytte data, ikke multiplicere.</p> Det relevante tal er hukommelsesbåndbredde</strong>:</p> RTX 4070 Ti: ~504 GB/s (GDDR6X, dedikeret VRAM-bus)</li> M1 Pro: ~200 GB/s (LPDDR5X, delt CPU/GPU)</li> </ul> Båndbredde-forhold: 2,5×</strong> — som matcher LLM-gennemstrømningsforholdet på 2,9–3,6× næsten præcist. M1 er langsommere fordi den har mindre hukommelsesbåndbredde, ikke fordi dens GPU er 18× svagere. Til LLM-inferens ved små batch-størrelser er det hukommelsesbåndbredde du reelt køber.</p> Unified memory-fordelen</h2> M1 Pro’s GPU har adgang til alle 16 GB</strong> unified memory. En RTX 4070 Ti med 12 GB dedikeret VRAM rammer en hård grænse: modeller større end ~11 GB fp16 passer ikke og falder tilbage til langsomt system-RAM via PCIe, hvilket kollapser gennemstrømningen.</p> Modelstørrelse (fp16)</th> M1 Pro 16GB</th> RTX 4070 Ti 12GB</th></tr></thead> 1–3B (~2–6 GB)</td> Kører hurtigt</td> Kører hurtigt</td></tr> 7B (~14 GB)</td> Kører hurtigt</td> Passer stramt; passer måske ikke</td></tr> 7B kvantiseret q4 (~4 GB)</td> Hurtigt</td> Hurtigt</td></tr> 13B kvantiseret q4 (~8 GB)</td> Hurtigt</td> Hurtigt</td></tr> 30B kvantiseret q4 (~18 GB)</td> Passer ikke</td> Passer ikke</td></tr> </tbody></table> For det almindelige use case — en kvantiseret 7B- eller 13B-model — fungerer begge maskiner komfortabelt. M1 Pro’s unified memory lader den indlæse en ukvantiseret 7B-model i fp16 der ville overløbe en 12GB RTX; RTX kører den samme model kvantiseret til q4 hurtigere samlet set.</p> Hvad 95 vs 279 tok/s faktisk føles som</h2> minicpm-v4.6 ved 95 tok/s på M1 Pro producerer tokens hurtigere end nogen læser. qwen3.5 ved 20 tok/s på M1 Pro er grænsen — man ser ord dukke op men det føles lidt langsomt. På RTX ved 74 tok/s er qwen3.5 komfortabelt.</p> Til interaktiv brug</strong>: 20–30 tok/s er gulvet for hvad der føles acceptabelt. Begge maskiner klarer det på den lille model; kun RTX klarer det komfortabelt på 6,6GB-modellen.</p> Til en batch-transskriptions- eller resumé-pipeline</strong> der kører kontinuerligt vinder RTX klart — 279 vs 95 tok/s betyder 3× gennemstrømningen med den samme model. Den danske voicelog-pipeline</a> der bruger Claude Code-subagenter som resumélag kører præcis denne slags vedvarende batch-arbejdsbyrde; en RTX 4070 Ti ville køre den samme arbejdsbyrde på en tredjedel af clock-tiden.</p> Strømforbrug</h2> Ingen instrumenter var tilkoblet for denne kørsel, men nominel TDP giver størrelsesordenen:</p> </th> Tomgang</th> Fuld GPU-belastning</th></tr></thead> M1 Pro MacBook Pro</td> ~5 W</td> ~25–30 W</td></tr> RTX 4070 Ti (kort alene)</td> ~15 W</td> ~200 W</td></tr> </tbody></table> M1 vinder afgørende på effektivitet. Ved 95 tok/s for ~25W og 279 tok/s for ~200W leverer RTX 2,9× ydelsen til 7–8× strømmen</strong> — så M1 er 2,5× mere effektiv per watt</strong> til LLM-inferens.</p> Hvilken maskine til lokal AI?</h2> Use case</th> Vælg</th></tr></thead> Interaktiv lokal assistent (7B–13B kvantiseret)</td> Begge — RTX hurtigere, M1 roligere og mere effektiv</td></tr> Vedvarende batch-inferens (transskribering, resuméer)</td> RTX 4070 Ti</strong> — 3× gennemstrømning</td></tr> Indlæsning af store fp16-modeller uden kvantisering</td> M1 Pro</strong> — unified memory, ingen VRAM-grænse</td></tr> Træning eller fine-tuning (LoRA)</td> RTX 4070 Ti</strong> — tensor cores, CUDA-økosystem</td></tr> Always-on hjemmeserver (elregning betyder noget)</td> M1 Pro</strong> — ~7–8× lavere GPU-strømforbrug</td></tr> Numerisk ML (CV, embeddings, matmul-tungt)</td> RTX 4070 Ti</strong> — 7–18× hurtigere</td></tr> </tbody></table> Benchmarks kørt på personligt hardware, juni 2026. LLM-gennemstrømning afhænger kraftigt af modelkvantisering, kontekstlængde og systembelastning — behandl disse tal som størrelsesordenssammenligninger, ikke absolutte specifikationer.</em></p> Ollama — komplet guide til lokal AI (2026) 2026-06-22T00:00:00+00:00 Ollama</strong> lader dig køre store sprogmodeller lokalt med én kommando: ollama run llama3.2</code>. Ingen API-nøgle, ingen abonnement, ingen data der forlader din maskine. Denne guide tager dig fra installation til færdig opsætning — inkl. REST API, Python og performance-tricks.</p> Installation</h2> Mac</h3> brew install ollama </code></pre> Start serveren:</p> ollama serve </code></pre> Eller som baggrundstjeneste der starter automatisk ved login:</p> brew services start ollama </code></pre> Linux</h3> curl -fsSL https://ollama.com/install.sh | sh </code></pre> Installationen sætter Ollama op som en systemd</code>-service der starter automatisk. Tjek status med:</p> systemctl status ollama </code></pre> Windows</h3> Download installationsfilen fra ollama.com</a> — den sætter sig op som en bakke-app og starter automatisk ved login.</p> Første model</h2> Pull og kør en model med én kommando:</p> ollama run llama3.2:3b </code></pre> Ollama downloader modellen første gang (~2 GB), cacher den i ~/.ollama/models/</code>, og åbner en interaktiv chat. /bye</code> afslutter.</p> For at downloade uden at åbne chat:</p> ollama pull qwen3.5 </code></pre> Hvilken model skal du vælge?</h2> Model</th> Størrelse</th> RAM/VRAM</th> Hvad den er god til</th></tr></thead> llama3.2:1b</code></td> 1.3 GB</td> 2 GB</td> Hurtigste option — god til klassificering, korte svar</td></tr> llama3.2:3b</code></td> 2.0 GB</td> 3 GB</td> Bedste startpunkt</strong> — kompetent, kører overalt</td></tr> llama3.1:8b</code></td> 4.9 GB</td> 6 GB</td> Solid alsidig model, god til kode og tekst</td></tr> qwen3.5</code></td> 6.6 GB</td> 8 GB</td> Anbefalet</strong> — 9.7B, 262k kontekst, stærk på dansk</td></tr> gemma4:12b</code></td> 7.6 GB</td> 9 GB</td> Googles model — meget god til instruktioner</td></tr> phi4:14b</code></td> 9.1 GB</td> 11 GB</td> Microsofts kompakte model, god til ræsonnering</td></tr> llama3.1:70b</code></td> 43 GB</td> 48 GB</td> Kraftfuld — kræver server med meget VRAM/RAM</td></tr> minicpm-v4.6</code></td> 1.6 GB</td> 2 GB</td> Multimodal — kan se billeder</td></tr> </tbody></table> Tommelfingerregel:</strong> vælg den største model der passer i din GPU’s VRAM. Modellen skal helst</em> ligge helt i VRAM — flyder den over til RAM, falder hastigheden dramatisk.</p> Søg og find alle tilgængelige modeller:</p> ollama search llama </code></pre> CLI cheat sheet</h2> # Kør interaktiv chat ollama run qwen3.5 # Kør med system-prompt fra kommandolinjen ollama run llama3.2:3b "Forklar TCP/IP i tre sætninger" # Pipe input ind cat artikel.txt | ollama run qwen3.5 "Opsummer dette" # List downloadede modeller ollama list # Vis modeldetaljer (parametre, kvantisering, kontekstlængde) ollama show qwen3.5 # Slet en model ollama rm llama3.2:1b # Kopiér og omdøb en model ollama cp qwen3.5 mit-projekt # Vis kørende modeller og VRAM-brug ollama ps </code></pre> REST API</h2> Ollama eksponerer en HTTP-API på localhost:11434</code>. Du kan bruge den direkte fra terminalen eller fra ethvert programmeringssprog.</p> Generér tekst</h3> curl http://localhost:11434/api/generate -d '{ "model": "qwen3.5", "prompt": "Hvad er forskellen mellem TCP og UDP?", "stream": false }' </code></pre> Vigtige felter i svaret:</p> { "response": "TCP er forbindelsesorienteret...", "eval_count": 142, "eval_duration": 1923000000, "prompt_eval_duration": 215000000 } </code></pre> eval_count / (eval_duration / 1e9)</code> giver tokens per sekund.</p> Chat (med historik)</h3> curl http://localhost:11434/api/chat -d '{ "model": "qwen3.5", "messages": [ {"role": "system", "content": "Du er en hjælpsom dansk assistent."}, {"role": "user", "content": "Hvad er hovedstaden i Danmark?"} ], "stream": false }' </code></pre> Streaming</h3> Sæt "stream": true</code> (standard) for at få tokens løbende:</p> curl http://localhost:11434/api/generate -d '{ "model": "qwen3.5", "prompt": "Skriv et digt om terminal-programmering", "stream": true }' | while IFS= read -r line; do echo "$line" | python3 -c "import json,sys; d=json.load(sys.stdin); print(d.get('response',''), end='', flush=True)" done </code></pre> Liste over downloadede modeller</h3> curl http://localhost:11434/api/tags </code></pre> Nyttige options</h3> curl http://localhost:11434/api/generate -d '{ "model": "qwen3.5", "prompt": "...", "stream": false, "options": { "temperature": 0.7, "num_predict": 500, "num_ctx": 8192, "top_p": 0.9, "seed": 42 } }' </code></pre> Option</th> Standard</th> Hvad det gør</th></tr></thead> temperature</code></td> 0.8</td> Kreativitet: 0 = deterministisk, 1+ = mere tilfældig</td></tr> num_predict</code></td> -1 (ubegrænset)</td> Max tokens at generere</td></tr> num_ctx</code></td> modelens standard</td> Kontekstvindue (tokens)</td></tr> seed</code></td> tilfældig</td> Fast seed → reproducerbare svar</td></tr> top_p</code></td> 0.9</td> Nucleus sampling</td></tr> </tbody></table> Python</h2> Ollama’s API er simpel nok til at bruge med urllib</code> — ingen ekstra pakker nødvendigt:</p> import urllib.request, json def ollama(prompt, model="qwen3.5", system=None): messages = [] if system: messages.append({"role": "system", "content": system}) messages.append({"role": "user", "content": prompt}) payload = json.dumps({ "model": model, "messages": messages, "stream": False, "options": {"temperature": 0} }).encode() req = urllib.request.Request( "http://localhost:11434/api/chat", data=payload, headers={"Content-Type": "application/json"} ) with urllib.request.urlopen(req) as resp: return json.load(resp)["message"]["content"] # Brug svar = ollama("Forklar forskellen mellem list og tuple i Python") print(svar) </code></pre> Foretrækker du en dedikeret pakke:</p> pip install ollama </code></pre> import ollama svar = ollama.chat( model="qwen3.5", messages=[{"role": "user", "content": "Hvad er Rust?"}] ) print(svar["message"]["content"]) </code></pre> Modelfile — tilpas en model</h2> En Modelfile</code> lader dig oprette en ny model baseret på en eksisterende — med fast system-prompt, temperatur og parametre.</p> Opret filen Modelfile</code>:</p> FROM qwen3.5 SYSTEM """ Du er en præcis dansk teknisk assistent. Svar altid på dansk. Vær kortfattet. Vis kodeeksempler når relevant. """ PARAMETER temperature 0.3 PARAMETER num_ctx 16384 </code></pre> Byg og brug den:</p> ollama create dansk-assistent -f Modelfile ollama run dansk-assistent "Hvad er en hash-tabel?" </code></pre> List dine brugerdefinerede modeller:</p> ollama list </code></pre> Du kan dele Modelfiles med kolleger — de puller bare base-modellen og kører ollama create</code>.</p> Performance-tips</h2> Flash Attention (anbefalet)</h3> Reducerer VRAM-brug og øger hastighed på lange kontekster:</p> OLLAMA_FLASH_ATTENTION=1 ollama serve </code></pre> På Mac via Homebrew, tilføj til ~/.zshrc</code>:</p> export OLLAMA_FLASH_ATTENTION=1 </code></pre> KV-cache kvantisering</h3> Halverer næsten VRAM-forbruget til kontekst-cachen, med minimal kvalitetstab:</p> OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve # halvt VRAM, ingen synlig forskel OLLAMA_KV_CACHE_TYPE=q4_0 ollama serve # endnu mindre, let kvalitetstab </code></pre> Parallelle requests</h3> Ollama håndterer som standard én request ad gangen. Til serverbrug:</p> OLLAMA_NUM_PARALLEL=4 ollama serve # 4 samtidige requests OLLAMA_MAX_LOADED_MODELS=2 ollama serve # hold 2 modeller i VRAM </code></pre> Se hvad der kører</h3> ollama ps # NAME ID SIZE PROCESSOR UNTIL # qwen3.5:latest ... 7.9 GB 100% GPU 4 minutes from now </code></pre> Modeller unloades automatisk efter 5 minutters inaktivitet. Skift timeout:</p> OLLAMA_KEEP_ALIVE=30m ollama serve # hold indlæst i 30 min OLLAMA_KEEP_ALIVE=-1 ollama serve # hold indlæst for evigt </code></pre> Som server på netværket</h2> Som standard lytter Ollama kun på localhost. Åbn for netværksadgang:</p> OLLAMA_HOST=0.0.0.0:11434 ollama serve </code></pre> Brug Tailscale</strong> til at eksponere din GPU-server sikkert på dit private netværk uden at åbne for internet:</p> # På serveren med RTX 4070 Ti: OLLAMA_HOST=0.0.0.0:11434 ollama serve # Fra din Mac via Tailscale: OLLAMA_HOST=gpu-box:11434 ollama run qwen3.5 # eller direkte via API: curl http://gpu-box:11434/api/generate -d '{"model":"gemma4:12b","prompt":"..."}' </code></pre> På Linux med systemd, tilføj env vars i service-filen:</p> sudo systemctl edit ollama </code></pre> [Service] Environment="OLLAMA_HOST=0.0.0.0:11434" Environment="OLLAMA_FLASH_ATTENTION=1" Environment="OLLAMA_KV_CACHE_TYPE=q8_0" </code></pre> sudo systemctl restart ollama </code></pre> OpenAI-kompatibelt API</h2> Ollama understøtter OpenAI’s API-format, så eksisterende kode der bruger openai</code>-pakken kører uden ændringer:</p> from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama", # kræves af klienten, ignoreres af Ollama ) response = client.chat.completions.create( model="qwen3.5", messages=[{"role": "user", "content": "Hvad er en linked list?"}] ) print(response.choices[0].message.content) </code></pre> Hvad koster det at køre?</h2> Ingenting — bortset fra strøm. En 7B-model på en RTX 4070 Ti (200W under load) koster ca.:</p> Brug</th> Strøm</th> Pris (3 kr/kWh)</th></tr></thead> 1 times chat (~50 req)</td> ~0,1 kWh</td> ~0,30 kr</td></tr> 1 dags batch-transskription</td> ~0,5 kWh</td> ~1,50 kr</td></tr> GPT-4o via API (samme mængde)</td> —</td> ~50–200 kr</td></tr> </tbody></table> På M1 Pro (25W) er strømomkostningen nærmest symbolsk.</p> Nyttige links</h2> ollama.com/library</a> — alle tilgængelige modeller</li> github.com/ollama/ollama</a> — kildekode og issues</li> API-reference: http://localhost:11434</code> når Ollama kører</li> </ul> Se også M1 Pro vs RTX 4070 Ti — GPU og LLM benchmarks</a> for konkrete tal på, hvad de to platforme leverer.</p> </blockquote> Rust vs Go vs C på Apple Silicon og Linux — benchmarks på rigtig hardware (2026) 2026-06-22T00:00:00+00:00 Kort fortalt —</strong> Fire benchmarks på to maskiner: Apple M1 Pro</strong> (arm64, macOS 26.6, clang 21) og Intel i5-13400F</strong> (x86_64, Ubuntu 24.04, gcc 13). På M1 matcher Rust C inden for støj på alle tests. På Linux x86 slår gcc rustc på rekursiv fib</strong> (1,5×) og Go’s fib falder til 2,9× langsommere end C</strong> — et meget større gab end på arm64. Den største overraskelse: Rust’s parallel sum er 2,8× hurtigere end C pthreads på x86</strong>, sandsynligvis fordi LLVM folder heltalsrækken til en lukket formel som løkken aldrig rent faktisk kører.</p> Opsætning</h2> </th> M1 Pro (arm64)</th> i5-13400F (x86_64)</th></tr></thead> Maskine</strong></td> Apple MacBook Pro</td> Desktop-PC</td></tr> RAM</strong></td> 16 GB</td> 125 GB</td></tr> OS</strong></td> macOS 26.6 (Sequoia)</td> Ubuntu 24.04</td></tr> C-compiler</strong></td> Apple clang 21.0, -O3 -march=native</code></td> GCC 13.3, -O3 -march=native</code></td></tr> Go</strong></td> 1.26.4 darwin/arm64</td> 1.22.4 linux/amd64</td></tr> Rust</strong></td> 1.96.0</td> 1.96.0</td></tr> Rust-flag</strong></td> -C opt-level=3 -C target-cpu=native</code></td> -C opt-level=3 -C target-cpu=native</code></td></tr> </tbody></table> Hvert benchmark kørtes tre gange; tabellerne nedenfor viser medianen af kørsel 2–3.</p> De fire benchmarks</h2> 1 — Primtalssold (primtal op til 10.000.000)</h3> Fladt bool-array-sold: skrive-tungt sekventiel hukommelsesadgang, letgrebet indre løkke. God proxy for hukommelsesbåndbredde-begrænset kode.</p> 2 — Rekursiv Fibonacci (n = 47)</h3> Ingen heap-allokering, ingen løkker — ~2,97 milliarder stakrammer. Måler rå kald-dispatch, grenforudsigelse og hvor aggressivt hver compiler inliner/optimerer dyb rekursion.</p> 3 — Matrixmultiplikation (512 × 512, f64, i-k-j løkkerækkefølge)</h3> Cache-venlig løkkerækkefølge men stadig en tæt FP-akkumulering i den indre løkke. Her betyder auto-vektorisering og eliminering af grænsecheck mest.</p> 4 — Parallel sum (100.000.000 heltal, 8 tråde)</h3> 8 POSIX-tråde (C), goroutines (Go) eller std::thread</code> (Rust), der hver summerer en partition af 0..100_000_000</code>. Tester tråd-spawn-overhead og hvor smart hver compiler håndterer den indre sum.</p> Resultater: Apple M1 Pro (arm64, clang 21, macOS)</h2> Benchmark</th> C</th> Go 1.26</th> Rust 1.96</th></tr></thead> Sold (10M primtal)</td> 13,3 ms</td> 19,3 ms</td> 12,3 ms</strong></td></tr> Fib(47) rekursiv</td> 8,86 s</td> 9,84 s</td> 8,91 s</td></tr> Matrixmultiplikation 512²</td> 24,7 ms</td> 80,2 ms</td> 24,1 ms</strong></td></tr> Parallel sum 100M</td> 3,0 ms</td> 10,7 ms</td> 3,4 ms</td></tr> </tbody></table> Resultater: Intel i5-13400F (x86_64, gcc 13, Linux)</h2> Benchmark</th> C</th> Go 1.22</th> Rust 1.96</th></tr></thead> Sold (10M primtal)</td> 25,7 ms</td> 34,3 ms</td> 27,6 ms</td></tr> Fib(47) rekursiv</td> 4,06 s</td> 11,86 s</strong></td> 6,02 s</td></tr> Matrixmultiplikation 512²</td> 22,5 ms</td> 106,7 ms</td> 28,3 ms</td></tr> Parallel sum 100M</td> 3,4 ms</td> 8,7 ms</td> 1,2 ms</strong></td></tr> </tbody></table> Median af 3 kørsler, kørsel 2 brugt. 2026-06-22.</em></p> Hastighed relativt til C, begge maskiner</h2> Benchmark</th> Go/C (M1)</th> Go/C (i5)</th> Rust/C (M1)</th> Rust/C (i5)</th></tr></thead> Sold</td> 1,45×</td> 1,33×</td> 0,92×</td> 1,07×</td></tr> Fib(47)</td> 1,11×</td> 2,92×</strong></td> 1,01×</td> 1,48×</td></tr> Matrixmultiplikation</td> 3,24×</td> 4,74×</strong></td> 0,98×</td> 1,26×</td></tr> Parallel sum</td> 3,57×</td> 2,56×</td> 1,13×</td> 0,35×</strong></td></tr> </tbody></table> Tre ting der er værd at forklare</h2> 1 — Go’s fib kollapser på x86</h3> På M1 var Go’s fib(47) 11% langsommere end C — i praksis det samme. På i5’en er det 2,9× langsommere</strong>. Samme Go-version, samme algoritme. Forskellen er compiler-backend’en: Go’s arm64-kodegeneration håndterer dybe rekursive kaldkæder mere effektivt end dens amd64-kodegeneration. Dette er et kendt kvalitetsgab; Go’s x86-backend er generelt mindre moden end arm64-backendet til rekursionstunge mønstre.</p> 2 — gcc slår rustc på rekursiv fib</h3> På M1 (clang mod rustc, begge bruger LLVM) tog fib ~8,9s i begge sprog — identisk. På Linux producerede gcc 4,06s mens rustc producerede 6,02s — gcc er 1,5× hurtigere</strong>. GCC’s optimizer anvender mere aggressiv tail-rekursion og inlining-heuristikker for dette specifikke mønster på x86. Det er en påmindelse om at “Rust bruger LLVM” ikke betyder at det altid vinder over gcc; GCC har 30+ år af x86-optimeringskunst bag sig.</p> 3 — Rust’s parallel sum er 2,8× hurtigere end C på x86</h3> Rust-trådens krop er (start..end).sum::<u64>()</code>. LLVM genkender en sum af en sammenhængende heltalsrækkevidde som en aritmetisk rækkeformel</strong> og erstatter løkken med en lukket beregning n(n+1)/2</code> — O(1), uanset rækkeviddens størrelse. GCC med den manuelle for (i = start; i < end; i++) s += i;</code>-løkke anvender SIMD-vektorisering men laver ikke spring til lukket form. Resultat: Rust’s otte tråde udfører hver én multiplikation; C’s otte tråde summerer hver 12,5M heltal. 2,8×-forskellen er udelukkende en compiler-optimeringsforkel, ikke en sprogforskel. (På arm64 var denne effekt mindre fordi Apple clang også anvender noget af denne optimering.)</p> Binærstørrelse og kompileringstid</h2> </th> C (macOS)</th> C (Linux)</th> Go (macOS)</th> Go (Linux)</th> Rust (macOS)</th> Rust (Linux)</th></tr></thead> Binærstørrelse (sold)</td> 33 KB</td> 16 KB</td> 2,5 MB</td> 1,9 MB</td> 431 KB</td> 4,3 MB</strong></td></tr> Kold kompilering (sold)</td> 96 ms</td> 54 ms</td> 319 ms</td> 193 ms</td> 660 ms</td> 134 ms</td></tr> </tbody></table> Rust-binæren der er 4,3 MB på Linux mod 431 KB på macOS</strong> er den mest slående størrelsesforkel. På macOS linker Rust mod system-dylibs for dele af standardbiblioteket og holder binæren lille. På Linux linker Rust alt statisk, hvilket producerer en større men fuldt selvstændig binær uden system-biblioteksafhængighed — en reel fordel til containere.</p> Kompileringstider vender: Rust er 134ms på Linux mod 660ms på macOS</strong> for en enkelt fil. LLVM’s x86_64-backend er markant hurtigere til at udsende kode end dens arm64-backend.</p> Anno 2026: hvor lever hvert sprog?</h2> C</strong> er stadig referencepunktet og stadig hurtigst på rå rekursivt arbejde når gcc’s optimizer er involveret. I 2026 er det ikke et førstehåndsvalg til nye projekter medmindre du skriver kernekode, embedded firmware eller FFI-klister — men compiler-kunsten akkumuleret siden 1972 er reel.</p> Go</strong> ramte 1.0 i 2012 med en klar tese: gør det at skrive netværkstjenester lige så hurtigt at udvikle som Python, mens man kører med effektiviteten af et kompileret sprog. Det har i høj grad lykkedes. Hvad det betaler for det: GC’en tilføjer latensvarians, og performance-loftet er lavere end Rust eller C for beregningstunge løkker. fib-resultatet på x86 afslører også at Go’s optimizer har reelle kvalitetsgab på visse mønstre — den er tunet til hvad Go-kode faktisk ligner (interfaces, kanaler, HTTP-handlere), ikke trærekursion.</p> Rust</strong> ramte 1.0 i 2015 og har brugt et årti på at bevise at hukommelsessikkerhed uden GC er opnåeligt i stor skala. I 2026 accepterer Linux-kernen Rust til drivere (siden 6.1), Firefox og Chromium erstatter gradvist C++ med det, og ISRG omskriver kritisk netværksinfrastruktur i det. Den lukkede formel-sum-optimering ovenfor er et godt eksempel på hvad “zero-cost abstractions” betyder i praksis: at skrive idiomatisk Rust lader compileren anvende transformationer som en manuel C-løkke ikke kan udløse.</p> Pick-one-guide</h2> Du vil…</th> Vælg</th></tr></thead> Skrive en Linux-driver eller kernemodul</td> C</strong> (eller Rust hvis subsystemet accepterer det)</td></tr> Bygge en mikrotjeneste eller CLI-værktøj hurtigt</td> Go</strong> — tooling + goroutines + hurtig iteration</td></tr> Skrive sikkerhedskritisk systemkode</td> Rust</strong> — borrowchecker, ingen GC, ingen UB</td></tr> Optimere en varm numerisk indre løkke</td> C</strong> eller Rust</strong> — SIMD, ingen grænsecheck, fuld LLVM</td></tr> Levere en statisk binær til en container</td> Go</strong> (statisk som standard) eller Rust (musl</code>)</td></tr> Målrette arm64-performance</td> Rust</strong> ≈ C, bedre end Go</td></tr> Målrette x86-rekursiv kode</td> C med gcc</strong> vinder; Rust konkurrencedygtig; Go halter</td></tr> </tbody></table> Benchmarks kørt på personligt hardware; dine tal vil variere med CPU, OS-indstillinger og compiler-flag. Koden er fire enkelt-fils programmer, ingen eksterne afhængigheder. Alle compilere kaldt med fulde optimeringsflag som vist ovenfor.</em></p> BIN/IIN-opslag: kort-præfiksernes intervaller og hvordan du slår et op (2026) 2026-06-10T00:00:00+00:00 Kort fortalt —</strong> Et korts første cifre — BIN</strong> (Bank Identification Number) / IIN</strong> (Issuer Identification Number) — identificerer netværket</strong> og udstederen</strong>. Du kan læse netværket</em> direkte ud af præfiksintervallerne (tabel nedenfor). Udsteder/bank/land</em> kræver en BIN-database</strong> — der er ingen formel for det. Denne side giver dig IIN-intervaltabellen</strong>, 6-vs-8-ciffer-forbeholdet</strong> og de tre måder at slå et BIN op på</strong> (i hånden, via side/API, programmatisk).</p> Baggrundslæsning på bloggen: hvorfor et 6-ciffers BIN nu er flertydigt</a> og historien bag binlist.net og iinlist.com</a>.</p> </blockquote> Hvad et BIN/IIN er</h2> Kortnummeret (PAN, primary account number) er struktureret: de første cifre er IIN’et</strong>, der identificerer den udstedende institution og netværket; resten er det individuelle kontonummer, med et afsluttende Luhn-kontrolciffer</strong>. “BIN” er det daglige branchebegreb; “IIN” er det formelle begreb i ISO/IEC 7812</strong>. IIN’et var 6 cifre</strong> i årtier og er udvidet til 8</strong> for de fleste netværk — se 8-ciffer-indlægget</a>.</p> IIN-præfiksintervaller pr. netværk</h2> Hvad du kan</em> bestemme ud fra præfikset alene — hvilket netværk der udstedte kortet:</p> Netværk</th> IIN-præfiksinterval(ler)</th> PAN-længde</th></tr></thead> Visa</strong></td> 4</code></td> 13, 16, 19</td></tr> Mastercard</strong></td> 51</code>–55</code>, 2221</code>–2720</code></td> 16</td></tr> American Express</strong></td> 34</code>, 37</code></td> 15</td></tr> Discover</strong></td> 6011</code>, 644</code>–649</code>, 65</code>, 622126</code>–622925</code></td> 16–19</td></tr> Diners Club Intl</strong></td> 36</code>, 300</code>–305</code>, 3095</code>, 38</code>–39</code></td> 14–19</td></tr> JCB</strong></td> 3528</code>–3589</code></td> 16–19</td></tr> UnionPay</strong></td> 62</code>, 81</code></td> 16–19</td></tr> Maestro</strong></td> 50</code>, 56</code>–69</code>, 6304</code>, 6759</code>, 676770</code>, 676774</code></td> 12–19</td></tr> RuPay</strong></td> 60</code>, 6521</code>, 6522</code></td> 16</td></tr> Mir</strong></td> 2200</code>–2204</code></td> 16</td></tr> Troy</strong></td> 9792</code></td> 16</td></tr> </tbody></table> Bemærk: intervaller kan overlappe i kanterne (f.eks. nogle 62</code> UnionPay vs. 622126</code>–622925</code> Discover-cobadging), og 50</code>/56</code>–69</code> for Maestro er bredt og kolliderer med andre — hvilket er præcis derfor, opløsning på udstederniveau kræver en database, ikke en præfiksregel.</p> Hvad du ikke</em> kan se ud fra præfikset</h2> Der er ingen formel</strong>, der oversætter et præfiks til et banknavn, land eller debit/kredit-flag. Den kobling ligger i en vedligeholdt BIN-database</strong> bygget af netværksbulletiner og observerede kort. Så:</p> Netværk</strong> → kan læses ud af tabellen ovenfor. ✅</li> Udstederbank, land, korttype, produkt, prepaid/debit/kredit</strong> → kun databaseopslag. ❌ i hånden.</li> </ul> Tre måder at slå et BIN op på</h2> 1. I hånden (kun netværk)</h3> Tag de første cifre og match dem mod tabellen ovenfor. Godt nok, når alt du har brug for er “er det Visa eller Mastercard?”.</p> 2. På en opslagsside / gratis API</h3> For detaljer på udstederniveau, brug en BIN-opslagstjeneste. Det velkendte gratis valg er binlist.net</strong>, som blotlægger et JSON-API:</p> curl https://lookup.binlist.net/45717360 </code></pre> { "scheme": "visa", "type": "debit", "brand": "Visa Classic", "bank": { "name": "Example Bank", "country": "..." }, "country": { "name": "United Kingdom", "alpha2": "GB" } } </code></pre> Det er rate-limited</strong> (en håndfuld forespørgsler i timen) og bedst til lejlighedsvise opslag. Til volumen, 8-ciffers granularitet og pålidelighed vil du have en licenseret database — iinlist.com</strong> er det kommercielle valg bygget til netop dette. (Baggrund: hvordan begge opstod</a>.)</p> Send kun BIN’et — de første 6-8 cifre — aldrig et fuldt kortnummer</strong> til et tredjepartsopslag. Præfikset er alt, et opslag behøver, og fulde PAN’er er følsomme (PCI) data.</p> 3. Programmatisk</h3> Til mere end det lejlighedsvise tjek: validér og normalisér først, slå så op:</p> # normalisér: fjern mellemrum, tag de første 8 cifre som BIN bin=$(echo "4571 7360 1234 5678" | tr -dc '0-9' | cut -c1-8) curl -s "https://lookup.binlist.net/$bin" </code></pre> Et hurtigt Luhn</strong>-gyldighedstjek, før du gemmer eller slår noget op (POSIX-shell):</p> luhn() { # returnerer 0 hvis nummeret består Luhn-tjekket echo "$1" | tr -dc '0-9' | rev | awk '{ s=0; for(i=1;i<=length;i++){d=substr($0,i,1); if(i%2==0){d=2; if(d>9)d-=9}; s+=d} exit (s%10!=0) }' } luhn "4571736012345678" && echo gyldig || echo ugyldig </code></pre> Til BIN-matching i produktion: indlæs en licenseret BIN-fil i din egen tabel, og key på 8 cifre</strong> med fallback til 6 med et lav-tillids-flag.</p> Opsummering</h2> BIN/IIN’et</strong> er kortnummerets første cifre — netværk + udsteder</strong>; 6 cifre historisk, 8 nu</strong>.</li> Du kan læse netværket</strong> ud af præfiksintervallerne</a>; udsteder/bank/land kræver en database</strong>.</li> Slå op: i hånden</strong> (netværk), en side/API</strong> som binlist.net (gratis, rate-limited) eller iinlist.com</strong> (kommerciel, 8-ciffer), eller programmatisk</strong>.</li> Send kun de første 6-8 cifre</strong>, aldrig et fuldt PAN, til noget tredjepartsopslag.</li> Foretræk 8-ciffers</strong> matching — se hvorfor 6 cifre nu er flertydigt</a>.</li> </ul> Transskribering af 33.000 danske voicelogs på hjemme-GPU'er — den lokale pipeline (2026) 2026-06-10T00:00:00+00:00 Kort fortalt —</strong> Forretningstelefonsamtaler var blevet optaget i over et år: ~33.000 danske mp3-filer, ~570 timer, 32 kbps telefonkvalitet</strong>. Opgaven var at transskribere det hele, navngive talerne, resumere pr. opkald / pr. dag / pr. uge, gøre det browsbart — og gøre det lokalt, uden LLM-API</strong>. Resultatet er en pipeline, der kører to ASR-modeller og fusionerer dem med Claude</strong>, identificerer talere fra metadata før noget lyd afkodes</strong>, heler sig selv over to GPU’er</strong>, og bruger Claude Code-subagenter som resumélag</strong> i stedet for et API. Her er hele bygget, og hvad det lærer om en kundeservicefunktion.</p> Den voksne efterfølger til at køre Whisper lokalt i stedet for et cloud-Speech-API</a>. Samme instinkt — hold lyden på din egen boks — i 33.000-fil-skala.</p> </blockquote> Begynd med at analysere ligene</h2> Mappen indeholdt allerede ni halvfærdige forsøg</strong> på problemet. Før der blev skrevet noget nyt, læste tre agenter alle ni. Tilsammen indeholdt de døde eksperimenter næsten alle de rigtige idéer, det endelige system havde brug for:</p> Ét Python-forsøg (WhisperX + pyannote + Claude-dagsresuméer) var det mest komplette — men havde hardcodede API-nøgler, en engelsk-alignment-bug på dansk lyd og mock-diarisering i den “rigtige” pipeline.</li> Ét havde opdaget nøgletricket: phone-first taleridentifikation</strong> (mere nedenfor) og havde allerede bygget stemmeprofiler.</li> En Go-omskrivning havde en flot service-arkitektur og et SQLite-skema — men alt var stubs</strong>; nul segmenter blev nogensinde gemt. Lektion: byg aldrig skallen, før signalvejen virker.</li> Et benchmark-harness havde allerede sammenlignet seks ASR-modeller</strong> på korpusset.</li> </ul> At syntetisere de ni var langt billigere end at opfinde fra bunden. Lektion ét: analysér ligene først.</strong></p> Modelbenchmarken</h2> Det eksisterende benchmark (på RTX 4070 Ti) plus en frisk sammenligning afgjorde modelvalget:</p> Model</th> Resultat</th></tr></thead> faster-whisper large-v3-turbo</strong></td> Hurtigst — ~37× realtid, 1,8 GB VRAM. God, men glider på støjende dansk.</td></tr> faster-whisper large-v3 (fuld)</strong></td> Mest kohærent på rigtige opkald. ~18× realtid — hurtig nok. Valgt.</strong></td></tr> hviske-v3-conversation</strong> (dansk fine-tune)</td> Fanger danske navne/vendinger, de andre forvansker. Valgt som andet spor.</strong></td></tr> Voxtral</strong></td> Hallucinerede i løkker (1.832 ord for et 117-sekunders opkald), sprog-bleed. Droppet.</strong></td></tr> vibevoice</strong></td> ~6× langsommere end realtid. Droppet.</strong></td></tr> </tbody></table> Den ikke-oplagte beslutning: kør to modeller, ikke én.</strong> large-v3 og hviske fejler forskelligt</strong> — den ene har grammatikken, den anden har de danske navne — så at beholde begge og fusionere dem slår hver for sig.</p> Pipelinen</h2> mp3 → ffmpeg båndpas (200–3400 Hz + let denoise + dynaudnorm) → 16 kHz mono → [A] faster-whisper large-v3 (int8_float16, beam 5, VAD, anti-løkke-guards) → [B] hviske-v3-conversation (dansk fine-tune) ← kun på opkald ≥45 s → ECAPA-TDNN-diarisering (token-fri klyngedeling, 2-taler-prior på lange opkald) → "phone-first" navngivning (filnavn + telefonbog forankrer identiteter; embeddings afgør hvilken klynge der er den gennemgående part; referenceprofiler matcher resten) → SQLite (idempotent: SHA-256-hash + status; dubletter arver tvillingens resultat) pr. dag → Claude-subagent læser BEGGE transskriptioner pr. opkald, fusionerer dem, retter diarisering ud fra kontekst, skriver dagsresuméet (dansk) pr. uge → Claude-subagent syntetiserer 7 dagsresuméer til tråde + en løftetabel web → Flask læser DB'en live (dage, uger, opkald m. audio, søgning, mønstre) </code></pre> Et par beslutninger gjorde sig fortjent:</p> Phone-first taleridentifikation.</strong> Filnavnet bærer tidsstemplet og begge numre; en lille telefonbog oversætter numre til navne. Man kender begge</em> identiteter, før et ord afkodes — lyden skal kun afgøre hvilken stemme der er hvem</em>, ikke hvem de er</em>. Metadata er guld.</strong></li> ffmpeg-båndpas hjælper; DeepFilterNet skader.</strong> Målt: et 50 år gammelt båndpasfilter gjorde støjende opkald mere kohærente gratis; den neurale SOTA-denoiser gav hallucinationer og tabt tale. SOTA er opgaveafhængigt.</strong></li> ECAPA frem for pyannote.</strong> pyannote løb tør for hukommelse ved siden af Whisper på et 12 GB-kort og var for langsom på CPU til 33k filer. Token-fri ECAPA-klyngedeling på GPU’en, med en 2-taler-prior</strong> (et telefonopkald er</em> to-parts), reddede de 79% af lange opkald, der ellers kollapsede til én taler.</li> int8_float16 + udvidelige segmenter</strong> lod begge</strong> modeller sameksistere i ~6–8 GB på 12 GB-kortet.</li> </ul> Resumélaget: Claude Code-subagenter, intet API</h2> Den hårde binding var ingen LLM-API-nøgle</strong>. Så harnesset selv er sprogmodellen: én Claude Code-subagent pr. dag</strong> får begge ASR-spor for hvert opkald, et fælles navneregister og gårsdagens resumé, og skriver dagsresuméet direkte — ~50k–450k tokens pr. dag-agent, intet API-kald i pipelinen, ingen marginalomkostning.</strong></p> Tre små “institutioner” voksede op omkring det:</p> En fusions-instruksfil</strong> — fletregler ([A]’s struktur, [B]’s danske ord), ret diarisering ud fra kontekst (en taler der nævner sit eget navn fastlægger, hvem der taler), spring voicemails over, opfind aldrig indhold, rapportér usikkerhed ærligt.</strong></li> Et fælles, voksende navneregister</strong> — agenterne læser det før skrivning og tilføjer nye afklaringer. Over 60+ dage forener det stavevarianter af samme kontakt til én bekræftet identitet og holder to ens-navngivne personer adskilt. Navnekonsistens over hele korpusset, lag på lag.</li> En ugentlig løftetabel</strong> — hver uges agent fører en “løfter & leverancer”-tabel videre (✅/⏳/❌). En reelt nyttig primitiv (og, som vi skal se, broen til kundeservice).</li> </ul> At køre det over to maskiner</h2> Idempotens gjorde korpusset deleligt midt i kørslen:</p> Maskine 1 (RTX 4070 Ti, 12 GB):</strong> hele dual-model-pipelinen, kronologisk fremad.</li> Maskine 2 (GTX 1060, 6 GB, Pascal):</strong> deployeret over SSH/Tailscale med ét script; tog en senere partition. Kører kun [A]-sporet i int8 (nye CUDA-wheels droppede Pascal, så torch er på CPU mens CTranslate2 driver GPU’en direkte).</li> Merge:</strong> workeren skriver sin egen SQLite; hovedmaskinen henter og merger hvert 15. minut (idempotent — transcribed</code> kan opgraderes til done</code>). Korpusset behandles fra begge ender på én gang.</strong></li> </ul> Fordi hver fil er nøglet på SHA-256-hash + status</strong>, var det harmløst at flytte halvdelen af arbejdet til en anden maskine midt i kørslen. Idempotens er friheden til at fejle.</strong></p> Selvheling, lært på den hårde måde</h2> Lange uovervågede kørsler fejler på kreative måder. Hver fejl fik et permanent modtræk:</p> To transkriptionsprocesser på én GPU</strong> (en forældreløs overlevede en genstart) → gensidig OOM-forgiftning, 756 fejlede rækker. Modtræk: en flock</code>-singleton i supervisoren + auto-drab af forældreløse ved opstart.</li> “Poison file”-myten</strong> — en fil så ud til at crashe processen igen og igen; det var i virkeligheden dual-proces-konflikten. Den kørte fint ved retry. Supervisoren fik retry-én-gang-så-karantæne-logik alligevel.</li> Tavse hæng</strong> — en worker hang i en time på én fil (proces i live, ingen fremdrift). Modtræk: en watchdog der dræber inder-processen efter 20 min uden DB-aktivitet (DB-mtime som fremdriftssignal).</li> En ydre watchdog hvert 10. minut</strong> tjekker supervisoren, DB-fremdrift og webserver lokalt — og det hele på workeren over SSH — og genstarter automatisk.</li> Falske “klar”-dage</strong> — en max-dato-heuristik erklærede en dag færdig, mens 93 af dens 104 filer stadig manglede. Modtræk: indbakken er ground truth</strong> — en dag/uge er først klar, når hver</em> fil har en afgjort DB-række. Ground truth slår heuristik; max-dato-gættet løj to gange, indbakke-optællingen aldrig.</strong></li> Anonyme opkald</strong> — filer fra et hemmeligt nummer matchede ikke filnavnsmønsteret og blev usynlige for dag-gruppering. Parser udvidet, rækker repareret.</li> En dublet-bug</strong> — identisk lyd under nyt navn blev markeret done</code> uden transskription (én hash delt af 103 tomme ring-ud-filer) og forurenede dag-dumps. Nu arver dubletter tvillingens status og indhold.</li> Høstede baggrundsprocesser</strong> — nohup</code>-jobs blev høstet af miljøet og døde ubemærket i timevis. Modtræk: alt langkørende arbejde som harness-managede baggrundstasks, med watchdoggen som bagstopper.</li> </ol> Selvheling skal være lagdelt:</strong> proces-niveau (supervisor: crash / hæng / poison / orphan) og</em> system-niveau (watchdog: supervisor død? web nede? worker væk?).</p> Tallene (pr. skrivende stund)</h2> </th> </th></tr></thead> Korpus</td> ~33.000 mp3, ~570 audiotimer, 13 måneder</td></tr> Behandlet</td> ~6.100 filer (19%), fra begge ender</td></tr> Resuméer</td> 60 dags- + 7 ugeresuméer</td></tr> Lokal hastighed</td> dual-model ~0,2 RTF; ~430 filer/time</td></tr> Dag-agent-omkostning</td> ~50k–450k subagent-tokens/dag (gns. ~200k)</td></tr> Diarisering</td> 2-taler-prior + kontekst-reparation reddede de 79% af lange opkald, der kollapsede til én stemme</td></tr> </tbody></table> Hvordan det kan bruges i en kundeservicefunktion</h2> Den oprindelige use case er personlig opkalds-intelligens, men præcis den samme pipeline er et kundeservice</strong>-system:</p> To-spors-ASR + LLM-fusion</strong> → præcise danske transskriptioner af supportopkald.</li> Resuméer pr. opkald / dag / uge</strong> → QA uden at lytte til hvert opkald.</li> Løftetabellen</strong> generaliserer direkte til SLA-/løfte-tracking</strong> — hvad en agent lovede en kunde, og om det blev leveret, ført videre uge for uge.</li> Det fælles navneregister</strong> → et konsistent kunde-/kontaktkartotek bygget fra opkaldene selv.</li> Mønster-visningen</strong> (volumen pr. time, retningsasymmetri, tilbagevendende emner) → bemandings- og eskaleringsindsigt, alt sammen fra metadata + resuméer.</li> PII-disciplin</strong> er indbygget: “opfind aldrig, flag usikkerhed”-reglen og redigering før noget gemmes.</li> </ul> Og privatlivshistorien er salgsargumentet: alt kører lokalt bag Tailscale</strong> — lyden forlader aldrig bygningen, du sætter opbevaring og redigering, og der er intet offentligt endpoint. (Den ærlige grænse: hvis dit sproglag er et cloud-LLM-API frem for et lokalt harness, forlader den tekst stedet — så redigér først, eller hold LLM’en lokal også.)</p> Lektionerne, destilleret</h2> Analysér ligene først</strong> — ni døde eksperimenter rummede næsten alle de rigtige idéer. Syntese slår opfindelse.</li> Metadata er guld</strong> — filnavne alene gav taleridentitet, dagsstruktur og hele mønsteranalysen, før et sekund lyd var afkodet.</li> To middelmådige, forskellige ASR-spor + en model der fletter dem slår ét godt spor.</strong> Fejl-diversitet er pointen.</li> SOTA er opgaveafhængigt</strong> — neural denoise skadede</em> ASR målbart; et 50 år gammelt båndpas hjalp.</li> Idempotens er friheden til at fejle</strong> — hash + status gjorde hvert crash, genstart og midt-i-kørslen-migrering harmløst.</li> Selvheling i lag</strong> — supervisor for processen, watchdog for systemet.</li> Ground truth frem for heuristik</strong> til fremdriftsgates — tæl indbakken, gæt ikke fra max-datoen.</li> En LLM kan være pipelinens dyre trin uden et API</strong> — når harnesset selv er modellen, er et “resumé-trin” en subagent med en god instruksfil, et fælles register og en ærlighedsnorm.</li> </ol> Nulstil en Yealink-telefon til fabriksindstillinger — også uden admin-adgangskoden (2026) 2026-06-10T00:00:00+00:00 Kort fortalt —</strong> For at fabriksnulstille en Yealink</strong> SIP-bordtelefon har du tre muligheder: tastaturmenuen</strong> (kræver admin-adgangskoden), web-UI’en</strong> (kræver admin-adgangskoden) eller et hardware-tastetryk</strong>, der slet ikke kræver adgangskode</strong> — hold OK</strong>-tasten i ~10 sekunder. Den sidste er den, du vil bruge til en brugt eller arvet telefon med ukendt admin-login. Dette dækker også standardadgangskode-situationen i 2026: gammel firmware er admin</code>/admin</code>, nyere enheder leveres med en unik adgangskode på en label</strong>.</p> Standardadgangskoden, dengang → nu</h2> Det her snubler folk over, så få det på plads først:</p> Ældre firmware:</strong> brugernavn admin</code>, adgangskode admin</code>. Den klassiske standard.</li> Nyere firmware (sikkerhedshærdning, ~2021 og frem):</strong> Yealink leverer hver telefon med en unik tilfældig standardadgangskode</strong> trykt på et klistermærke (typisk på undersiden eller æsken), eller tvinger dig til at sætte en ny adgangskode ved første web-login. Så admin</code>/admin</code> virker ikke</strong> på nyere enheder.</li> </ul> Hvis du har adgangskoden, så nulstil fra menuen eller web-UI’en. Hvis du ikke har den, så spring til hardware-nulstillingen</strong> — den rydder adgangskoden helt.</p> Metode 1 — Hardware-nulstilling (ingen admin-adgangskode nødvendig)</h2> Det er den, de fleste søger efter. Med telefonen tændt og i hviletilstand</strong> (ikke i et opkald, ikke i en menu):</p> Tryk og hold OK-tasten</strong> — den runde/midterste tast under skærmen — i cirka 10 sekunder</strong>.</li> Skærmen viser “Nulstil til fabriksindstillinger?”</strong></li> Tryk OK</strong> for at bekræfte.</li> Telefonen sletter alt og genstarter. Det tager et minut eller to; afbryd den ikke.</li> </ol> Intet login nødvendigt — dette nulstiller admin-adgangskoden sammen med alt andet. (På enkelte modeller udløses prompten ved at holde X</strong>-/annuller-tasten i stedet; hvis OK ikke gør det, så prøv den.)</p> Metode 2 — Fra telefonens tastatur (kræver admin-adgangskode)</h2> Tryk på Menu</strong>-softtasten.</li> Gå til Indstillinger → Avancerede indstillinger</strong>, og indtast admin-adgangskoden (admin</code> på gammel firmware, eller label-adgangskoden).</li> Vælg Nulstil til fabriksindstillinger</strong> (nogle gange Reset Config</strong>), og bekræft.</li> </ol> Metode 3 — Fra webgrænsefladen (kræver admin-adgangskode)</h2> Find telefonens IP: Menu → Status</strong> (eller Indstillinger → Status</strong>).</li> Gå til http://<telefon-ip>/</code>, og log ind som admin</code>.</li> Gå til Settings → Upgrade</strong> (eller Reset & Reboot</strong>), og klik Reset to Factory</strong>.</li> </ol> Efter nulstillingen</h2> En fuld nulstilling sletter SIP-kontoen, netværkskonfigurationen, kontakter og opkaldshistorik</strong> — telefonen kommer tilbage som ny. Før du nulstiller (hvis du kan logge ind), så notér dine SIP-oplysninger</strong> (server/registrar, brugernavn, auth-ID, adgangskode), så du kan genregistrere den bagefter. På nyere firmware bliver du bedt om at sætte en frisk admin-adgangskode ved første login igen.</p> Opsummering</h2> Ingen admin-adgangskode?</strong> Hold OK</strong>-tasten ~10 s i hviletilstand → bekræft → færdig. Intet login nødvendigt.</li> Har adgangskoden?</strong> Nulstil fra Menu → Indstillinger → Avanceret</strong>, eller web-UI’en</strong> på http://<telefon-ip>/</code>.</li> Standardadgangskode:</strong> admin</code>/admin</code> på gammel firmware; en unik label-adgangskode</strong> på nyere enheder.</li> En fabriksnulstilling sletter SIP-kontoen og kontakter</strong> — gem dine SIP-oplysninger først.</li> </ul> Opdater Garmin-firmware og -kort i 2026 — fra WebUpdater til Garmin Express 2026-06-10T00:00:00+00:00 Kort fortalt —</strong> Hvis du søgte efter Garmin WebUpdater</em> eller hvordan opdaterer jeg Garmin-firmware</em>, er værktøjet, du husker, væk. WebUpdater blev nedlagt (~2015)</strong>; den nuværende vej er Garmin Express</strong> (et skrivebordsprogram, USB-kabel) til nüvi/DriveSmart-navigatorer, eller Garmin Connect</strong> (telefon, trådløst) til ure og nyere håndholdte. Dette indlæg dækker 2026-måden at opdatere firmware og kort</strong> på hver, hvad du gør med en gammel nüvi, og den skjulte nüvi-debugmenu</strong>.</p> Dengang → nu: WebUpdater er død</h2> I årevis opdaterede du en Garmin med WebUpdater</strong> — en lille skrivebordshjælper, der tjekkede for firmware. Garmin pensionerede den og samlede alt i to apps:</p> Garmin Express</strong> — skrivebord (Windows/macOS), forbinder via USB-kabel</strong>. Det er det, der erstattede WebUpdater til navigatorer (nüvi, DriveSmart, Drive) og er også kabelvejen til ure/håndholdte og kort</strong>opdateringer.</li> Garmin Connect</strong> — telefon-app (iOS/Android), opdaterer trådløst</strong> over Bluetooth/Wi-Fi. Det er vejen til ure (Forerunner, fēnix, Venu), cykelcomputere (Edge) og moderne håndholdte.</li> </ul> Hvis du stadig har WebUpdater installeret, så afinstallér det — det gør ikke længere noget nyttigt.</p> Opdater en nüvi / DriveSmart-navigator (firmware + kort)</h2> Det er tilfældet bag de fleste “opdater Garmin-firmware”-søgninger.</p> Hent Garmin Express</strong> fra garmin.com/express</a> og installér det på en Windows- eller Mac-computer.</li> Tilslut enheden med et USB-kabel</strong> og tænd den. Vent på, at computeren genkender den som et drev.</li> Åbn Garmin Express. Den finder enheden og viser tilgængelige software- (firmware)</strong> og kort</strong>opdateringer.</li> Klik Installér alle</strong>, eller vælg enkelte opdateringer. Kortfiler er store (ofte flere GB) — lad den være tilsluttet, og afbryd ikke midt i.</li> Når den er færdig, så skub sikkert ud og frakobl. Enheden genstarter med den nye firmware.</li> </ol> Kortopdateringer</strong> vises også her. Hvis din enhed har lifetime maps</strong> (“LM”/“LMT” i modelnavnet), er opdateringer gratis i enhedens understøttede levetid. Ellers tilbyder Express et betalt kortkøb.</p> Opdater et ur / Edge / nyere håndholdt (trådløst)</h2> Installér Garmin Connect</strong> på din telefon, og parr enheden.</li> Connect henter opdateringer automatisk; du får en besked, når firmware er klar.</li> Hold enheden opladt og nær telefonen — den installerer og genstarter af sig selv.</li> </ol> For en kabelopdatering af disse enheder (eller hvis trådløst fejler) virker Garmin Express på en computer også.</p> Meget gamle nüvi-enheder — hvad der stadig virker</h2> Mange tidlige nüvi-modeller (2007–2012-æraen) er nu udgået</strong>: firmware kan måske stadig installeres via Garmin Express, men kortopdateringer tilbydes ikke længere</strong>, og lifetime-maps-dækningen er ophørt. Hvis Express viser “opdateret” med et gammelt kortår, er det som regel vejs ende — hardwaren understøttes simpelthen ikke med nye kortdata mere. Enheden virker fortsat med de kort, den har.</p> Bonus: den skjulte nüvi-debugmenu</h2> Et gammelt trick til at diagnosticere en ustabil nüvi: tænd den, og tryk og hold nederste højre hjørne af berøringsskærmen</strong> i nogle sekunder. En diagnoseskærm</strong> dukker op — softwareversion, kalibreringstest af berøringsskærm, GPS-signaltest, batteriinfo. Det er sikkert at se på; undgå at ændre berøringsskærmskalibrering, medmindre skærmen reelt er skæv.</p> Opsummering</h2> WebUpdater er nedlagt</strong> — brug Garmin Express</strong> (skrivebord, USB) eller Garmin Connect</strong> (telefon, trådløst).</li> nüvi / DriveSmart</strong>: Garmin Express over USB klarer både firmware og kort; “Installér alle”.</li> Ure / Edge / håndholdte</strong>: Garmin Connect opdaterer trådløst.</li> Lifetime maps</strong> (LM/LMT-modeller) opdaterer gratis; meget gamle nüvi-enheder er udgået for nye kortdata.</li> nüvi-debugmenu</strong>: hold nederste højre hjørne af skærmen efter opstart.</li> </ul> Whisper-backend-dyst: faster-whisper vs HF Transformers vs whisper.cpp (2026) 2026-06-10T00:00:00+00:00 Kort fortalt —</strong> På et RTX 4070 Ti med telefoni-optimeret lydforbehandling når faster-whisper</code> med large-v3-turbo</code> ~56× realtid</strong> — hurtigst samlet. whisper.cpp</code> CUDA er tæt på (~40×)</strong> ved en brøkdel af VRAM’en. Batched HF Transformers</strong> (SDPA, batch 24) er konkurrencedygtig på turbo-modellen. På CPU matcher whisper.cpp</code> overraskende GPU-hastigheder for korte filer; faster-whisper</code> int8 er stadig praktisk ved ~5×.</p> En del af det danske voicelog-projekt</a> — dette er backend-benchmarken bag pipelinens ASR-valg. Se også at køre Whisper lokalt</a>.</p> </blockquote> Opsætning</h2> </th> </th></tr></thead> GPU</strong></td> NVIDIA GeForce RTX 4070 Ti (12 GB VRAM)</td></tr> CPU</strong></td> Intel Core i5-13400F (16 tråde)</td></tr> RAM</strong></td> 125 GB</td></tr> CUDA</strong></td> 12.9 / Driver 595</td></tr> faster-whisper</strong></td> 1.2.1 (CTranslate2 4.8.0)</td></tr> transformers</strong></td> 5.10.2</td></tr> whisper.cpp</strong></td> kompileret fra kilde, CUDA aktiveret</td></tr> PyTorch</strong></td> 2.12.0</td></tr> </tbody></table> Lyd-testsæt</h2> Tre rigtige danske telefonopkald fra et dansk voicelog-korpus (filnavne anonymiseret til Fil 1–3</code>):</p> Fil</th> Varighed</th> Noter</th></tr></thead> Fil 1</strong></td> 1m 26s</td> Autentisk dansk samtaletale</td></tr> Fil 2</strong></td> 13m 26s</td> Autentisk dansk samtaletale</td></tr> Fil 3</strong></td> 1m 51s</td> Autentisk dansk samtaletale</td></tr> </tbody></table> Der findes ingen referencetransskriptioner — kvalitet vurderes via konsensus-WER</strong> (parvis enighed på tværs af modeller) og relativ WER</strong> (afstand til konsensus-vinderen).</p> </blockquote> Backends i test</h2> Backend</th> Engine</th> Nøgleteknik</th> Modeller</th></tr></thead> faster-whisper</strong></td> CTranslate2</td> int8/float16-kvantiserede kerner</td> large-v3, large-v3-turbo</td></tr> HF Transformers (batched)</strong></td> PyTorch (SDPA)</td> batch_size=24, flash-attention via SDPA</td> large-v3, large-v3-turbo</td></tr> whisper.cpp</strong></td> ggml</td> CUDA-kerne-offload / AVX CPU</td> large-v3, large-v3-turbo</td></tr> </tbody></table> Resultater: hastighed (RTF — lavere er bedre)</h2> RTF = transskriptionstid ÷ lydvarighed. RTF 0,03 = 33× realtid.</em></p> Backend / Model / Enhed</th> Fil 1</th> Fil 2</th> Fil 3</th> Gns. RTF</strong></th> Fart</strong></th></tr></thead> faster-whisper / large-v3-turbo / CUDA</td> 0.021</td> 0.013</td> 0.019</td> 0.018</strong></td> 56×</strong></td></tr> faster-whisper / large-v3 / CUDA</td> 0.047</td> 0.033</td> 0.051</td> 0.043</strong></td> 23×</strong></td></tr> HF Transformers (b24, SDPA) / large-v3-turbo / CUDA</td> 0.040</td> 0.062</td> 0.036</td> 0.046</strong></td> 22×</strong></td></tr> HF Transformers (b2, SDPA) / large-v3 / CUDA</td> 0.180</td> 0.142</td> 0.222</td> 0.181</strong></td> 6×</strong></td></tr> whisper.cpp / large-v3-turbo / CUDA</td> 0.028</td> 0.017</td> 0.030</td> 0.025</strong></td> 40×</strong></td></tr> whisper.cpp / large-v3 / CUDA</td> 0.070</td> 0.050</td> 0.080</td> 0.067</strong></td> 15×</strong></td></tr> faster-whisper / large-v3-turbo / CPU</td> 0.208</td> 0.151</td> 0.248</td> 0.203</strong></td> 5×</strong></td></tr> faster-whisper / large-v3 / CPU</td> 0.470</td> 0.354</td> 0.714</td> 0.513</strong></td> 2×</strong></td></tr> whisper.cpp / large-v3-turbo / CPU</td> 0.034</td> 0.017</td> 0.027</td> 0.026</strong></td> 39×</strong></td></tr> whisper.cpp / large-v3 / CPU</td> 0.071</td> 0.050</td> 0.084</td> 0.068</strong></td> 15×</strong></td></tr> </tbody></table> Resultater: VRAM-forbrug (GPU-kørsler)</h2> Backend / Model</th> Gns. VRAM (MB)</th></tr></thead> HF Transformers (b24, SDPA) / large-v3-turbo / CUDA</td> 3884</td></tr> HF Transformers (b2, SDPA) / large-v3 / CUDA</td> 5727</td></tr> </tbody></table> Resultater: kvalitet (konsensus-WER)</h2> Konsensus-WER måler, hvor meget hver models output afviger fra gruppegennemsnittet. Lavere = mere lig det, alle modeller er enige om.</p> Backend / Model / Enhed</th> Fil 1</th> Fil 2</th> Fil 3</th> Gns. relativ WER</th></tr></thead> faster-whisper / large-v3-turbo / CUDA</td> 0.132</td> 0.359</td> 0.226</td> 0.239</strong></td></tr> faster-whisper / large-v3 / CUDA</td> 0.230</td> 0.334</td> 0.294</td> 0.286</strong></td></tr> HF Transformers (b24, SDPA) / large-v3-turbo / CUDA</td> 0.237</td> 0.601</td> 0.229</td> 0.356</strong></td></tr> HF Transformers (b2, SDPA) / large-v3 / CUDA</td> 0.152</td> 0.225</td> 0.326</td> 0.234</strong></td></tr> whisper.cpp / large-v3-turbo / CUDA</td> 0.000</td> 0.673</td> 0.000</td> 0.224</strong></td></tr> whisper.cpp / large-v3 / CUDA</td> 0.187</td> 0.000</td> 0.553</td> 0.247</strong></td></tr> faster-whisper / large-v3-turbo / CPU</td> 0.136</td> 0.344</td> 0.191</td> 0.224</strong></td></tr> faster-whisper / large-v3 / CPU</td> 0.249</td> 0.339</td> 0.274</td> 0.287</strong></td></tr> whisper.cpp / large-v3-turbo / CPU</td> 0.000</td> 0.673</td> 0.000</td> 0.224</strong></td></tr> whisper.cpp / large-v3 / CPU</td> 0.187</td> 0.000</td> 0.553</td> 0.247</strong></td></tr> </tbody></table> Kvalitetsvinder:</strong> faster-whisper / large-v3-turbo / CPU</code></p> </blockquote> Side om side: hvor backendsne adskilte sig</h2> Test-lyden er et privat opkald, så i stedet for at gengive det er her en neutral dansk sætning, der står som stedfortræder for den slags samtaletale, der blev testet — plus de afvigelsesmønstre, der faktisk dukkede op på tværs af backends på 86-sekunders-filen:</p> “Lad os tage mødet på torsdag, så gennemgår vi tallene sammen.”</em> (illustrativ)</p> </blockquote> Tabte indledninger.</strong> faster-whisper</code> large-v3 (CUDA og CPU) startede nogle gange et par ord inde og udelod en indledende sætning, som turbo-modellerne og whisper.cpp</code> fangede.</li> Uenighed om egennavne.</strong> Det indledende navn blev transskriberet på to forskellige måder på tværs af backends — det klassiske problem med navne i et sprog med få ressourcer, hvor hver model gætter en anden plausibel stavemåde.</li> Forvanskede navneord på støjende segmenter.</strong> whisper.cpp</code> large-v3 lavede et klart navneord om til en næsten-homofon, som turbo-modellerne fik rigtigt.</li> Sjældne hallucinerede fragmenter.</strong> faster-whisper</code> large-v3 udsendte lejlighedsvis en kort nonsens-frase på en støjende strækning, hvor de andre backends holdt sig rene.</li> Mindre stavefejl.</strong> Turbo-CPU-kørslen producerede en og anden vokal-tastefejl, der ikke sås på GPU.</li> </ul> Netto: turbo-modellerne var mest konsekvent kohærente</strong>; fuld large-v3 var stærk, men mere tilbøjelig til tabte indledninger og en og anden hallucination på denne støjende telefonlyd.</p> Nøglefund</h2> Hurtigste GPU:</strong> faster-whisper / large-v3-turbo / CUDA</code> ved gns. RTF 0,018 (56× realtid).</li> Turbo-speedup (faster-whisper GPU):</strong> large-v3-turbo er 2,4× hurtigere end large-v3.</li> Hurtigste CPU:</strong> whisper.cpp / large-v3-turbo / CPU</code> ved gns. RTF 0,026.</li> GPU vs. CPU (faster-whisper turbo):</strong> GPU er 11,4× hurtigere end CPU int8.</li> Lavest VRAM:</strong> HF Transformers (b24, SDPA) / large-v3-turbo / CUDA</code> ved 3884 MB.</li> </ul> Anbefalinger</h2> Use case</th> Anbefaling</th></tr></thead> Produktions-pipeline (GPU-server)</strong></td> faster-whisper</code> + large-v3-turbo</code> + float16</code> — bedste hastighed/kvalitet/VRAM</td></tr> Højeste præcision (GPU, ingen hastighedsbinding)</strong></td> faster-whisper</code> + large-v3</code> + float16</code></td></tr> Batched offline-behandling</strong></td> HF Transformers batched (SDPA) + large-v3-turbo</code>, batch_size=24</td></tr> Embedded / ingen Python-runtime</strong></td> whisper.cpp</code> CUDA — én binær, lavt overhead</td></tr> CPU-only-server</strong></td> faster-whisper</code> + large-v3-turbo</code> + int8</code></td></tr> Edge / Raspberry Pi</strong></td> whisper.cpp</code> CPU + large-v3-turbo</code> (mindste RAM-fodaftryk)</td></tr> </tbody></table> Metodenoter</h2> Hver backend/model/enhed-kombination kører som en separat proces</strong> for at garantere fuld GPU-hukommelses-frigivelse mellem kørsler.</li> faster-whisper GPU bruger compute_type=float16</code>; CPU bruger int8</code>.</li> HF Transformers bruger attn_implementation=sdpa</code> (PyTorch SDPA / FlashAttention-ækvivalent, ingen ekstra installation).</li> whisper.cpp bruger CUDA automatisk, når den er kompileret med GGML_CUDA=ON</code> — intet flag nødvendigt; CPU-kørsler bruger -t 8</code> (systemets trådantal).</li> Al lyd forbehandles med ffmpeg før transskribering: highpass=f=200,lowpass=f=3400,afftdn=nr=10:nf=-25,dynaudnorm</code> (telefon-båndpas + let denoise + loudness-normalisering).</li> VRAM måles via torch.cuda.max_memory_allocated()</code>; ikke tilgængeligt for whisper.cpp-subprocess-kørsler.</li> Al lyd er dansk samtale-telefontale — resultater kan variere på andre sprog eller lydforhold.</li> Konsensus-WER beregnes parvist på tværs af alle modeller; modellen med lavest gennemsnitlig parvis WER er “konsensus-vinderen”.</li> </ul> Fra Launchy til Raycast: tastaturstarterens historie (2007 → 2026) 2026-06-07T00:00:00+00:00 TL;DR —</strong> I 2007 lagde jeg en kort screencast op af Launchy</a></strong> — en “tastaturstyret applikationsstarter”, der lod dig fremkalde ethvert program på Windows ved at trykke en genvejstast og skrive nogle få bogstaver, i stedet for at lede i Start-menuen. Det mønster — genvejstast → skriv → fuzzy-match → start</strong> — blev født på Mac’en (Quicksilver, LaunchBar), kom til Windows med Launchy, spredte sig til Linux og gjorde så to ting på én gang: den modnedes til fulde produktivitetsplatforme (Alfred</strong>, så Raycast</strong>), og den opløste sig i Cmd+K-kommandopaletten</strong>, der nu bor inde i næsten alle apps, du bruger. Her er buen over 19 år.</p> En pendant til de andre tidskapsel-indlæg her — som Xming på Windows XP → WSLg</a> og 25 års Wi-Fi-sikkerhed</a>. En gammel screencast, og hvad idéen voksede til.</p> </blockquote> Opsætningen, dengang</h2> Videoen</a> (“Shiny Windows Application Launcher” — Shiny</em> var et Launchy-skin) viser arbejdsgangen fra 2007. Du installerer Launchy</strong>, den indekserer din Start-menu, og fra da af:</p> Tryk Alt+Space</strong>. En lille gennemsigtig boks dukker op midt på skærmen.</li> Skriv nogle få bogstaver — fir</code> for Firefox, wor</code> for Word.</li> Launchy fuzzy-matcher mod alt, den har indekseret, og viser det bedste hit.</li> Tryk Enter</strong>. Appen starter. Boksen forsvinder.</li> </ol> Ingen mus, ingen Start-menu, ingen skrivebordsikoner. Efter en uge kendte dine fingre tre-bogstavs-præfikset for hver app, du brugte. Launchy — skrevet af Josh Karlin og open-sourcet — blev udtrykkeligt markedsført som “Quicksilver til Windows”</strong>, og den sammenligning er nøglen til hele historien.</p> Hvor idéen faktisk kom fra</h2> Launchy opfandt ikke tastaturstarteren — den bragte en Mac</strong>-idé til Windows:</p> LaunchBar</strong> (Objective Development) — bedstefaderen, med rødder på NeXTSTEP i 1990’erne</strong>, genfødt på Mac OS X. Skriv en forkortelse, få tingen.</li> Quicksilver</strong> (Nicholas Jitkoff / Blacktree, ~2003) — den legendariske, nærmest mystiske Mac-starter. Ikke bare “start en app”, men en verbum-navneord-grammatik: vælg en ting</em>, vælg en handling</em>, vælg et mål</em>. Den definerede genren og inspirerede en hel generation (den blev open-sourcet i 2007, da skaberen tog til Google).</li> Spotlight</strong> (Mac OS X Tiger, 2005) — Apple bagte søgning ind i styresystemet, hvilket er der, de fleste almindelige brugere mødte “skriv bare for at finde ting”-idéen.</li> </ul> Launchy (2004→) var Windows-svaret på alt det, og videoen fra 2007 er et øjebliksbillede af den på toppen.</p> Et hurtigt overblik — 19 år med startere</h2> Æra</th> macOS</th> Windows</th> Linux</th> Mønsteret</th></tr></thead> ~2003–05</strong></td> Quicksilver, LaunchBar, Spotlight</td> Start-menu (Vista får søgning, 2007)</td> —</td> Starteren er en Mac-power-user-ting</td></tr> 2007 (videoen)</strong></td> Quicksilver på toppen</td> Launchy</strong> (“Quicksilver til Windows”)</td> —</td> Tastaturstarteren krydser til Windows</td></tr> ~2008–10</strong></td> Quicksilver stagnerer → Alfred</strong> (2010)</td> Launchy topper, så sløver</td> GNOME Do</strong>, Katapult</td> Starteren bliver mainstream-power-user</td></tr> ~2011–15</strong></td> Alfred + Powerpack dominerer</td> Wox (2014)</td> Synapse, Albert</td> Kommandopaletten</strong> dukker op (Sublime, så VS Code)</td></tr> ~2016–20</strong></td> Raycast</strong> grundlægges (2020)</td> PowerToys Run</strong> (2020), Flow Launcher</td> Rofi, Ulauncher</td> Cmd+K spreder sig til hver web-app</td></tr> 2026 (i dag)</strong></td> Raycast dominerer; Spotlight + Apple Intelligence</td> PowerToys Command Palette</strong>; Raycast (beta)</td> Rofi / Ulauncher / Albert</td> Starteren = AI-drevet kommando-hub</td></tr> </tbody></table> Hvad der ændrede sig</h2> 1. Starteren blev en platform.</strong> Launchy startede apps og filer. Alfred</strong> (2010) tilføjede workflows</em> — kæd handlinger sammen, kør scripts, udklipshistorik, snippets — og blev Mac-standarden i et årti. Så genopbyggede Raycast</strong> (2020) idéen som en native, udvidelig platform: en udvidelsesbutik, vinduesstyring, udklipshistorik, snippets, lommeregnere og nu indbygget AI</strong>. Den ydmyge start-boks blev til stedet, hvor power-brugere kører halvdelen af deres dag. Raycasts Windows-beta kom sidst i 2025</strong> og lukkede ringen tilbage til der, hvor Launchy startede.</p> 2. Windows blev ved med at genopfinde den.</strong> Launchy ebbede ud efter ~2010. Wox</strong> (open source, 2014) bar faklen videre og affødte Flow Launcher</strong> (en Wox-fork med en plugin-markedsplads og AI-plugins). Microsoft selv udgav PowerToys Run</strong> (2020, Alt+Space</code> — et vidende nik til Launchy), nu afløst af PowerToys Command Palette</strong>. Mønsteret er så åbenlyst godt, at OS-producenten adopterede det.</p> 3. Linux havde altid sin egen.</strong> GNOME Do</strong> (2008) var den tidlige Quicksilver-lignende; i dag er det Rofi</strong> og dmenu</strong> (minimale, scriptbare, elskede af tiling-WM-brugere), Ulauncher</strong> og Albert</strong>. Samme muskelhukommelse, andet økosystem.</p> 4. Det største skift: starteren opløste sig i hver app.</strong> Det definerende træk i det seneste årti er ikke en bedre starter — det er, at kommandopaletten</em> blev en universel UX-primitiv. Sublime Text</strong> (~2011) og så VS Code</strong> (Ctrl/Cmd+Shift+P</code>) gjorde “tryk en genvejstast, skriv en kommando” til måden, man styrer en editor på. Så dukkede Cmd+K</strong> op overalt: Slack, Linear, Notion, GitHub, Figma, Vercel, Stripe, din browser. Tastaturstarteren holdt op med at være en separat app, du installerer, og blev en kontrol indbygget i selve softwaren. I terminalen er fzf</strong> (2013) den samme idé destilleret til én fuzzy-finder-binær.</p> 5. Så åd AI’en kommandobaren.</strong> Den nyeste drejning: boksen, du skriver i, taler nu med en model. Raycast AI</strong>, Flow Launchers AI-plugins, Spotlight + Apple Intelligence</strong>, Windows Copilot</strong>. “Genvejstast → skriv → fuzzy-match → handl” bliver til “genvejstast → spørg → starteren regner handlingen ud”. Launchys lille gennemsigtige boks var larvestadiet for nutidens AI-kommandobar.</p> Hvad du skal bruge i dag</h2> macOS</strong> — Raycast</a></strong> er den moderne standard: start, udklipshistorik, vinduesstyring, snippets, en udvidelsesbutik og AI i én genvejstast. Alfred</a></strong> er alternativet, hvis du foretrækker et engangskøb og lokal automatisering. Spotlight er indbygget og efterhånden ret god.</p> Windows</strong> — PowerToys Command Palette</strong> (officiel, gratis, følger med PowerToys</a>), Flow Launcher</a></strong> (open source, plugin-markedsplads) eller Raycast</strong> (Windows-beta siden sidst i 2025). Par hvilken som helst af dem med Everything</a></strong> til lynhurtig filsøgning.</p> Linux</strong> — Rofi</strong> eller dmenu</strong> til den scriptbare/tiling-flok, Ulauncher</strong> eller Albert</strong> til en venligere GUI.</p> Terminal</strong> — fzf</a></strong>. Pipe hvad som helst ind i den, fuzzy-find, handl. Starter-idéen i 30 linjers muskelhukommelse.</p> Pointen</h2> Launchy-klippet fra 2007 ser gammeldags ud — en gennemsigtig boks, et Shiny-skin, tre bogstaver og Enter. Men idéen i det vandt fuldstændigt. Den begyndte som en Mac-kuriositet, Launchy bragte den til Windows, Linux samlede den op, og derfra gik den i to retninger på én gang: opad</em> til produktivitetsplatforme som Raycast, og sidelæns</em> ind i hver app som Cmd+K-kommandopaletten. I dag bruger du den idé fra 2007 snesevis af gange om dagen — du installerer den bare ikke længere, for den er overalt. Og boksen er begyndt at tænke.</p> FAQ</h2> Hvad var Launchy?</h3> En gratis, open source tastaturstarter til Windows (senere på tværs af platforme), først udgivet af Josh Karlin omkring 2004. Genvejstast, skriv nogle få bogstaver, fuzzy-match, start — “Quicksilver til Windows”. Videoen fra 2007 viser den på Shiny-skinnet.</p> Vedligeholdes Launchy stadig?</h3> Nej — udviklingen ebbede ud omkring 2010, og den er reelt gået i dvale. På Windows i dag: brug PowerToys Command Palette, Flow Launcher eller Raycast.</p> App-starter vs. kommandopalette — hvad er forskellen?</h3> Samme mønster, anden afgrænsning. En starter (Quicksilver, Launchy, Alfred, Raycast) er systemdækkende; en kommandopalette (VS Codes Ctrl+Shift+P</code>, Cmd+K</code>-baren i Slack/Linear/GitHub) er den samme UX inde i én app. Starteren kom først; paletten er den absorberet ind i alting.</p> Hvad skal jeg bruge i 2026?</h3> macOS: Raycast eller Alfred. Windows: PowerToys Command Palette, Flow Launcher eller Raycast. Linux: Rofi, Ulauncher eller Albert. Terminal: fzf.</p> Opsummering</h2> Tastaturstarteren — genvejstast → skriv → fuzzy-match → start</strong> — begyndte på Mac’en (LaunchBar</strong>, Quicksilver</strong>) og nåede Windows via Launchy</strong>, som min video fra 2007</a> demonstrerer.</li> Den voksede opad</em> til platforme: Alfred</strong> (2010) → Raycast</strong> (2020), nu AI-drevet, med en Windows-beta</strong> fra sidst i 2025.</li> Windows blev ved med at genopfinde den: Wox</strong> → Flow Launcher</strong>, og Microsofts PowerToys Run → Command Palette</strong>.</li> Den spredte sig også sidelæns</em> ind i hver app som Cmd+K-kommandopaletten</strong> (Sublime/VS Code → Slack, Linear, Notion, GitHub) og ind i terminalen som fzf</strong>.</li> Idéen fra 2007 er nu overalt — og i stigende grad en AI-kommandobar.</li> </ul> Fra Xming på Windows XP til WSLg: 18 år med Linux-GUI-apps på Windows (2026) 2026-06-07T00:00:00+00:00 TL;DR —</strong> At køre en Linux-GUI-app på en Windows-maskine plejede at betyde, at man installerede en X-server</strong> (Xming, senere VcXsrv), pegede en SSH-session på den med ssh -X</code> og så et fjernt gedit</code>-vindue tegne sig selv op på Windows-skrivebordet. Jeg har en gammel skærmoptagelse af præcis det</a> — Xming, der sætter gedit på Windows XP</strong>. Atten år senere gider man stort set ikke: WSLg</strong> leverer en Wayland- + X-server inde i</em> Windows, så en Linux-app installeret i WSL2 bare åbner som ethvert andet vindue. Dette indlæg trækker buen op — X11-forwarding → VcXsrv → Wayland → WSLg — og hvad du faktisk skal bruge i 2026.</p> Det her er en pendant til de andre “dengang vs. nu”-noter på bloggen — som lokal tale-til-tekst, der afløser cloud-Speech-API’en</a> og 25 års Wi-Fi-sikkerhed</a>. Samme form: noget, der var fummelt i XP-æraen, er nu indbygget.</p> </blockquote> Opsætningen, dengang</h2> Videoen</a> viser det kanoniske trick fra midten af 00’erne. Delene:</p> Xming</strong> — en gratis X11-server til Windows (en port af X.Org-serveren). Den kørte i Windows’ systembakke og leverede et display</em>, som X-klienter kunne tegne til.</li> En SSH-klient</strong> — som regel PuTTY med “Enable X11 forwarding” sat til, eller ssh -X</code> fra Cygwin.</li> En fjern Linux-maskine</strong>, der kørte selve appen (gedit</code>, en editor) uden noget lokalt vindue af sin egen.</li> </ul> Flowet: SSH forbinder til Linux-værten, værten sætter $DISPLAY</code> til at tunnelere X11 tilbage gennem den krypterede SSH-kanal, appen tegner til Xming, og et Linux-vindue dukker op på Windows XP. Applikationen kører udelukkende på fjern-maskinen; kun pixels og input-events</em> rejser. Det virkede, fordi X11 var netværkstransparent fra dag ét</strong> — en designbeslutning fra 1984, der modnede til en reelt nyttig egenskab.</p> Det var smart, og det var også langsomt og skrøbeligt: hver menu og genoptegning var en round-trip, så over andet end et LAN føltes det som at vade gennem sirup.</p> Et hurtigt overblik — 18 år med Linux-GUI på Windows</h2> Æra</th> Sådan gjorde du</th> Hvad drev displayet</th> Smertepunkter</th></tr></thead> ~2007 (XP)</strong></td> ssh -X</code> / PuTTY → Xming</td> Xming X-server i bakken</td> Manuel install, snakkesalig X11, laggy over WAN</td></tr> ~2012</strong></td> Samme, eller X over VNC</td> Xming / Xming-mesa, VcXsrv kommer (2011)</td> X-server stadig en separat bevægelig del</td></tr> ~2017</strong></td> VcXsrv + WSL1</td> VcXsrv, sæt DISPLAY=localhost:0</code></td> WSL1-finurligheder, font-/clipboard-fejl</td></tr> ~2021</strong></td> WSL2 + manuel X-server, eller</em> WSLg-preview</td> VcXsrv / X410, så WSLg</td> Overgang; manuel DISPLAY</code>-eksport stadig normal</td></tr> 2026 (i dag)</strong></td> WSLg, indbygget</td> Weston (Wayland) + XWayland, automatisk</td> Stort set ingen — apt install</code>, appen åbner</td></tr> </tbody></table> Hvad der faktisk ændrede sig</h2> 1. X-serveren holdt op med at være din at administrere.</strong> I ~25 år var X-serveren noget, du</em> installerede og passede på Windows. Med WSLg</a> — annonceret ved Microsoft Build 2021, nu standard på Windows 11 og Windows 10 21H2+ — bundter Microsoft en hel display-stak ind i en system-distro: en Weston</strong> Wayland-compositor, XWayland</strong> til gamle X11-apps, en PulseAudio-server til lyd og et RDP-link, der tegner vinduerne op på Windows-skrivebordet. Du installerer en Linux-GUI-app i WSL2, og den åbner. Ingen DISPLAY</code>, intet bakke-ikon, ingen PuTTY-afkrydsning.</p> # Inde i WSL2 på Windows 11 — ingen X-server at installere: sudo apt update && sudo apt install -y gedit gedit # et rigtigt Linux-gedit-vindue åbner på Windows </code></pre> 2. Wayland afløste X11 på Linux-siden.</strong> Protokollen, der gjorde det oprindelige trick muligt, er på vej ud. Moderne Linux-skriveborde defaulter til Wayland</strong>, som — i modsætning til X11 — ikke</em> er netværkstransparent. Så “bare forward det over SSH”-reflekset passer ikke længere rent; det Wayland-native svar på fjern-visning er waypipe</code></a>, og XWayland holder gamle X11-apps kørende i mellemtiden.</p> 3. Xming selv visnede til en betalt niche.</strong> Xming lever stadig — Colin Harrison udgav 7.7.x-builds så sent som januar 2026 — men den frit tilgængelige offentlige udgave frøs ved 6.9.0.31 i 2007</strong>; nyere versioner er donations-låst. Den gratis, aktivt vedligeholdte fakkel gik videre til VcXsrv</a></strong>, en open source-X-server bygget fra nuværende X.Org-kilder. (Bemærk: VcXsrv droppede Windows XP-understøttelse for længst — den æra er reelt forbi.)</p> 4. Selve grunden</em> fordampede stort set.</strong> I 2007 forwardede man en editor, fordi det var smertefuldt at redigere fjern-filer på nogen anden måde. I 2026 ville du gribe efter VS Codes Remote-SSH</strong>, montere fjern-filsystemet med sshfs</a> eller bare arbejde i en terminal over nøglebaseret SSH</a>. At forwarde et enkelt GUI-vindue er nu undtagelsen, ikke arbejdsgangen.</p> Hvad du skal bruge i dag</h2> Du er på WSL2 (Windows 11 / Win10 21H2+):</strong> gør ingenting. WSLg er der allerede. apt install</code> appen og kør den. Tjek med:</p> echo $WAYLAND_DISPLAY # wayland-0 → WSLg er aktiv echo $DISPLAY # :0 → XWayland til gamle X11-apps </code></pre> Du skal forwarde en GUI-app fra en fjern Linux-server til Windows:</strong> installér VcXsrv</strong>, start den (multiple-windows-tilstand, slå adgangskontrol fra — kun på et betroet netværk), og:</p> ssh -X user@server # -Y til betroet forwarding, hvis -X er blokeret xterm # eller hvilken GUI-app som helst — den tegner til VcXsrv </code></pre> Det er præcis</em> den samme mekanisme som i Xming-klippet, bare med en moderne X-server. Det virker stadig. Det er stadig snakkesaligt over latency.</p> Du vil have fjern-GUI, der ikke kravler over WAN:</strong> drop rå X11. Brug xpra</code></a> (“screen for X” — apps overlever afbrydelser, og det komprimerer godt), waypipe</code> til Wayland eller en rigtig remote-desktop-protokol (RDP via xrdp</code>, eller NoMachine/NX) til et fuldt skrivebord.</p> Pointen</h2> XP-klippet er en lille tidskapsel: en bakke-ikon-X-server, en PuTTY-tunnel og en Linux-teksteditor, der materialiserer sig på et beige XP-skrivebord. Idéen</em> — kør appen derovre, se den herovre — forsvandt aldrig. Det, der ændrede sig, er, at du ikke længere samler det i hånden. X-serveren flyttede ind i Windows, X11 gav plads til Wayland, og det almindelige tilfælde (“jeg vil bare røre filer på den maskine”) fik bedre svar helt af sig selv. Atten års VVS, stille og roligt absorberet ind i apt install</code>.</p> FAQ</h2> Virker SSH X11-forwarding stadig i 2026?</h3> Ja — ssh -X</code> (eller -Y</code> til betroet forwarding) er uændret. Det forwarder X11 til en hvilken som helst X-server: VcXsrv, Xming, XQuartz eller WSLg’s. Det er bare snakkesaligt over latency, hvilket er grunden til, at xpra/waypipe/RDP som regel vinder til fjern-arbejde i dag.</p> Vedligeholdes Xming stadig?</h3> Builds dukker stadig op (7.7.x i 2026), men de er donations-låst; den sidste gratis offentlige udgave var 6.9.0.31 i 2007 — Windows XP-æraen for klippet. Vil du have en gratis, aktivt bygget X-server til Windows, så brug VcXsrv.</p> Skal jeg overhovedet bruge en X-server?</h3> Kun til at forwarde GUI-apps fra en fjern maskine over SSH, eller til at køre X-apps fra en ikke-WSLg-distro. På WSL2 med Windows 11 (eller Win10 21H2+) leverer WSLg allerede en — lokale Linux-GUI-apps åbner uden noget ekstra installeret.</p> Hvorfor brød Wayland det gamle “forward det over SSH”-trick?</h3> X11 var netværkstransparent af design, så forwarding var gratis. Wayland er det bevidst ikke — fjern-visning er et separat anliggende, der håndteres af waypipe eller RDP. WSLg dækker over det ved at køre Weston + XWayland, så begge slags app virker.</p> Opsummering</h2> Den gamle måde: installér Xming</strong>, sæt X11-forwarding til i PuTTY, ssh -X</code>, og en fjern Linux-app tegner op på Windows. Videoen</a> er det, på Windows XP.</li> I dag: WSLg</strong> leverer en Wayland- + X-server inde i Windows — apt install</code> en Linux-app i WSL2, og den åbner bare.</li> VcXsrv</strong> er den gratis, vedligeholdte afløser for Xming til det klassiske fjern-forwarding-tilfælde; Xming</strong> selv blev donations-kun efter 6.9.0.31 (2007).</li> Wayland</strong> afløste X11’s netværkstransparens; brug waypipe</strong>, xpra</strong> eller RDP til hurtig fjern-GUI.</li> For den oprindelige motivation — at redigere på en fjern maskine — foretræk VS Codes Remote-SSH, sshfs</a> eller almindelig SSH</a>.</li> </ul> Forlæng videoklip med AI på en 12 GB GPU — seks modeller sammenlignet 2026-06-07T00:00:00+00:00 Kort fortalt —</strong> At “forlænge” et videoklip er i virkeligheden billede-til-video</strong>: tag sidste frame, lad en model generere en troværdig fortsættelse, og sæt dem sammen. Jeg kørte det samme maskine-klip gennem seks</strong> I2V-modeller på ét 12 GB RTX 4070 Ti</strong>: Wan2.2-TI2V-5B, Wan2.2-I2V-A14B (GGUF Q4, ved 640 px og ved 720p), Stable Video Diffusion, LTX-Video og CogVideoX-5B. Pointen er ikke vinderen — men at en 14B</strong>-model og 720p</strong> begge passer i 12 GB, når man får offload-strategien</strong> rigtig.</p> Opgaven</h2> Jeg havde en stak korte klip af skovmaskiner — en gravemaskine, en flishugger, en gummiged — og ville have dem et par sekunder længere. Der er ikke mere materiale; den eneste måde at forlænge på er at opfinde</em> det. Moderne billede-til-video-modeller gør netop det: de betinges på et startbillede (her klippets sidste frame) og en tekst-prompt og hallucinerer bevægelse fremad. Sæt den ægte hale sammen med den genererede fortsættelse, og du har et længere klip.</p> Alt nedenfor kørte lokalt på ét 12 GB RTX 4070 Ti med 125 GB system-RAM (RAM’en betyder noget — det er der de offloadede vægte bor).</p> Det egentlige problem: at få store videomodeller ned i 12 GB</h2> Billed-diffusion er tilgivende på VRAM. Video-diffusion er ikke: man denoiser et 3D-latent (frames × højde × bredde), og de nyeste kvalitetsmodeller er 5B-14B parametre. Tre ting bed hele tiden:</p> Tekstenkoderen er enorm.</strong> Wan, LTX og CogVideoX bruger alle en T5-XXL / umT5-XXL-enkoder på ~11 GB alene. I det øjeblik model-offload flytter den til et 12 GB-kort for at enkode prompten, OOM’er du — før videomodellen overhovedet kører.</li> Aktiveringer, ikke vægte, eksploderer ved højere opløsning.</strong> En 9 GB-transformer kan sidde på kortet fint; det er attention-aktiveringerne over (frames × tokens), der løber over, når man presser forbi ~480p.</li> Kvantisering hjælper på disk og lidt på VRAM, men spiller dårligt sammen med visse offload-tilstande.</strong> GGUF Q4 skrumper en 14B-ekspert til ~9 GB, men hvordan man offloader den betyder noget.</li> </ol> Det der fik det hele til at virke:</p> Præ-enkod prompten på CPU, og smid så enkoderen ud.</strong> Beregn tekst-embeddings med T5 på CPU’en i fp32</em> (bf16-matmuls på CPU er ulideligt langsomme — det ligner at den hænger), cast resultatet til bf16, sæt text_encoder = None</code>, og start så først videomodellen. Nu rører de 11 GB enkoder aldrig GPU’en.</li> Vælg offload-tilstand pr. model:</strong> enable_model_cpu_offload()</code> — flytter hele del-modeller ind/ud af GPU’en. Hurtig, men én model skal kunne være der ad gangen (så den begrænser opløsning/længde).</li> enable_sequential_cpu_offload()</code> — streamer del-moduler. Lavere top-VRAM, langsommere. Glimrende til ikke-kvantiserede modeller (LTX, CogVideoX), men bryder GGUF</strong> (accelerates meta-enhed-trin mister kvant-typen).</li> apply_group_offloading(..., offload_type="leaf_level", use_stream=True)</code> — streamer transformeren blad for blad. Det er hemmelige våben.</li> </ul> </li> </ul> Wan2.2: fra “fake” 5B til ægte 720p</h2> Jeg startede med Wan2.2-TI2V-5B</strong> (den lille, forbrugervenlige). Den kører nemt med model-offload og laver sammenhængende bevægelse, men ved de ~640 px kortet tillader, ser den blød ud — den klassiske plastik-agtige “AI-video”-fornemmelse.</p> At gå op til Wan2.2-I2V-A14B</strong> krævede kvantisering. Den officielle 14B er to eksperter (high-noise + low-noise) og vil have 24-35 GB i fp16. GGUF Q4-versionen er ~9 GB pr. ekspert, og diffusers kan loade hver via WanTransformer3DModel.from_single_file(..., quantization_config=GGUFQuantizationConfig(...))</code> — man skal bare have gguf</code>-pakken, ellers kan filen ikke læses. Med model-offload + CPU-prompt-tricket kører 14B’en ved 640 px, og bevægelsen er synligt bedre (flishuggeren, et kaotisk nærbillede som 5B’en lavede til grød, kom ud sammenhængende).</p> Så det egentlige mål: 720p</strong>. Model-offload ved 1280×720 topper ved ~11,7 GB — den passer, men kun ~13 frames før aktiveringerne løber over. Gennembruddet var group-leaf-offloading</strong>: stream transformeren ét bladmodul ad gangen, så næsten intet sidder på GPU’en. Top-VRAM ved 1280×720: 1,9 GB</strong>. Kortet er pludselig tomt og opløsning er gratis; prisen er hastighed (blad-streaming er langsomt, ~20 min pr. klip). Men det er ægte, skarp 720p på et 12 GB-kort.</p> from diffusers.hooks import apply_group_offloading for t in (pipe.transformer, pipe.transformer_2): # begge støj-eksperter apply_group_offloading(t, onload_device=torch.device("cuda"), offload_device=torch.device("cpu"), offload_type="leaf_level", use_stream=True) pipe.vae.enable_tiling() </code></pre> De andre tre</h2> LTX-Video</strong> (2B). Hurtig og, til korte forlængelser, den bedste af bundtet — dynamisk bevægelse (gravemaskinen kaster jord), prompt-styret, ~3 min pr. klip ved 768×512. Kræver sentencepiece</code> til sin T5-tokenizer, og sequential</code> offload, fordi den T5 er den samme 11 GB OOM-fælde.</li> Stable Video Diffusion</strong> (img2vid-xt). Veteranen. Kører ved 1024×576 med model-offload + unet.enable_forward_chunking()</code>, og den er hurtig — men SVD har ingen tekst-prompt</strong>, så dens bevægelse er ambient</em> (en blid glidning, vind i træerne) frem for den styrede action du bad om. God til filmiske cutaways, forkert værktøj til “bliv ved med at grave”.</li> CogVideoX-5B-I2V</strong>. Kvalitets-overraskelsen: det længste og blødeste klip (6 s, 49 frames ved 720×480), sammenhængende hele vejen. Hagen er hastigheden — med sequential offload + VAE-tiling tager det groft sagt en time pr. klip</strong> på 12 GB, hvilket gør den upraktisk her, selvom outputtet er smukt.</li> </ul> Resultattavlen</h2> Model</th> Parametre</th> Passer i 12 GB via</th> Output</th> Hastighed</th> Dom</th></tr></thead> LTX-Video</td> 2B</td> sequential offload</td> 768×512</td> ~3 min</td> Bedst til korte forlængelser</strong> — hurtig, dynamisk</td></tr> Wan2.2-I2V-14B @ 720p</td> 14B (Q4)</td> group-leaf-offload (1,9 GB!)</strong></td> 1280×720</td> ~20 min</td> Ægte 720p på 12 GB</strong> — skarpest</td></tr> Wan2.2-I2V-14B</td> 14B (Q4)</td> model-offload + CPU-prompt</td> 640×384</td> ~8 min</td> God bevægelse, især de svære tilfælde</td></tr> CogVideoX-5B-I2V</td> 5B</td> sequential + VAE-tiling</td> 720×480</td> ~1 time</td> Længst/blødest, men upraktisk langsom her</td></tr> Stable Video Diffusion</td> ~1,5B</td> model-offload + chunking</td> 1024×576</td> ~2 min</td> Hurtig og ren, men bevægelsen er ambient</td></tr> Wan2.2-TI2V-5B</td> 5B</td> model-offload</td> 640×384</td> ~3 min</td> Den bløde, “fake”-agtige baseline</td></tr> </tbody></table> Hvad jeg faktisk ville gøre</h2> På et 12 GB-kort: grib LTX-Video</strong> til hurtige, styrede forlængelser, og Wan2.2-14B + group-offload</strong> når du specifikt har brug for 720p</strong> og kan vente. SVD bliver i kassen til ambient cutaways. CogVideoX er smuk, men man ville ønske sig en større GPU for at bruge den i praksis.</p> Og den ærlige begrænsning: det der stadig læses som “AI” er mest opløsning</strong>. Group-offload køber dig 720p eller</em> et 12 GB-kort køber dig længde — ikke begge på én gang. Høj opløsning og</em> flere sekunder er den ene mur et 12 GB-kort ikke kan bestige; det er hvad et 24 GB+ kort (eller en time i skyen) er til. Alt andet — selv en 14B-model ved 720p — viste sig at være et spørgsmål om offloading, ikke hestekræfter.</p> Fem måder at skaffe b-roll fra én tur — alt på en lokal GPU 2026-06-02T00:00:00+00:00 Kort fortalt —</strong> B-roll er de klip, der giver en redigering luft, og onboard-POV fra ét kamera har præcis ingen. Jeg tog én ATV-tur og prøvede fem</strong> måder at fabrikere b-roll ud af den: (1) auto-mine</strong> de bedste rigtige frames med OpenCV, (2) generér stills</strong> og seed dem fra rigtige frames med SDXL-Turbo → RealVisXL img2img</strong>, (3) fake et filmisk kamera-move med Depth-Anything-V2</strong>-parallakse i 2,5D, (4) generér ægte bevægelse</em> med Stable Video Diffusion</strong>, og (5) lav et slowmotion</strong>-klip af det rigtige materiale med optisk flow-interpolation. Alt kørte lokalt på et 12 GB RTX 4070 Ti. De supplerer hinanden — her er sammenligningen og fælderne.</p> Problemet</h2> Onboard-materiale — et GoPro/DJI på styret af en gokart eller en ATV — er ét langt førstepersons-shot. Det er fremragende til action, men en redigering har brug for cutaways</em>: etableringsbilledet, naturen, den langsomme detalje, der giver seeren et åndedrag mellem de intense passager. Med ét kamera og intet B-kamera har du ingen. Så: kan man fabrikere troværdig b-roll bagefter, lokalt og gratis?</p> Jeg prøvede fem tilgange på én 11-minutters ATV-tur gennem nordisk skov og grusspor. Hver laver et kort, gradet klip; det interessante er afvejningerne.</p> 1. Auto-mine det rigtige materiale (OpenCV)</h2> Den billigste b-roll er den, du allerede har filmet uden at lægge mærke til det. En lille OpenCV-rutine sampler ~1.400 frames hen over turen og giver hver en score for skarphed</strong> (variansen af Laplacian), farverigdom</strong> (Hasler–Süsstrunk-målet), eksponering</strong> (afstand fra en mellemtone) og bevægelses-stabilitet</strong> (forskel mellem frames — lavt er godt til en stabil cutaway). Non-maximum suppression spreder derefter valgene ud, så du ikke får otte næsten identiske frames fra de samme 20 sekunder.</p> score = 1.1z(skarphed) + 1.0z(farverig) + 0.8z(eksponering) - 0.9rystelse - 6.0klipning </code></pre> Ikke glamourøst, men øjeblikkeligt, gratis og 100 % ægte. Outputtet er din egen tur — bare de mest b-roll-værdige tre sekunder, du havde glemt, du filmede.</p> 2. Generative stills, matchet til den rigtige tur</h2> Her blev det interessant — og her gik det først galt.</p> Forsøg ét: ren text-to-image.</strong> SDXL-Turbo med prompts som “filmisk diset skov i gyldent lys”</em> lavede smukke billeder, der lignede selve turen i ingenting. Forkert lys (solnedgang vs. den rigtige overskyede himmel), ingen ATV i billedet, intet POV. Flot stock-materiale af en</em> skov, ikke denne</em>.</p> Forsøg to: img2img, seedet fra rigtige frames.</strong> Ved at fodre et rigtigt frame ind som init-billede ved moderat denoising-strength bevares den rigtige komposition — den sorte ATV’s styr og spejle i forgrunden, det græs-og-jord-spor, den overskyede palette — og detaljen regenereres. Nu klipper det sammen med det rigtige materiale. Men SDXL-Turbo</strong> ved strength ≈0,5 smeltede</em> stadig: den hallucinerede ekstra instrumenter på instrumentbrættet og forvrængede styret. Det klassiske “AI-look”.</p> Forsøg tre: bedre modeller, lavere strength.</strong> Jeg sammenlignede tre mindre-smeltende metoder på de samme frames:</p> </p> SDXL-base, lav strength (0,30), 30 steps</strong> — tro mod kilden, ingen smelt, men en anelse blød.</li> ControlNet-Canny + SDXL</strong> — låser de rigtige kanter, så intet forvrænger, men komponerede scenen grønnere og mere stiliseret end kilden.</li> RealVisXL</strong> (en fotorealistisk SDXL-finetune), img2img — vinderen: skarp, fotorealistisk, bevarer det rigtige POV og palette, ingen smelt.</li> </ul> </p> Læren: til at matche materiale betyder basismodellen</em> og denoising-strength</em> langt mere end prompten. En fotorealistisk checkpoint ved lav strength slår en prangende destilleret model hver gang.</p> 3. AI Ken Burns — dybde-parallakse</h2> Et stillbillede behøver ikke stå stille. Depth-Anything-V2</strong> estimerer et dybdekort for et frame på et godt stykke under et sekund; med dybde i hånden kan du rendere et 2,5D-kamera-move, hvor nære pixels flytter sig mere end fjerne, plus et blidt skub mod sporets forsvindingspunkt. Det læser som at køre fremad.</p> </p> Hele renderingen er en baglæns cv2.remap</code> med dybdevægtet forskydning, så den er hulfri og hurtig. Én fælde værd at notere: OpenCV’s remap</code> vil have float32</code>-maps, og en enkelt løs Python-skalar i regnestykket opgraderer dem stille til float64</code>, hvorefter remap</code> fejler. Cast dem eksplicit tilbage til float32</code>.</p> Det er den bedste indsats-per-effekt af de syntetiske muligheder: rigtigt indhold, ægte-udseende bevægelse, en lillebitte model. Den eneste begrænsning er, at store skub begynder at afsløre forvrængning ved dybde-spring — hold bevægelsen diskret.</p> 4. Generativ video — Stable Video Diffusion</h2> Vil du have bevægelse, som et stillbillede ikke</em> kan fake, animerer Stable Video Diffusion</strong> (image-to-video) et stillbillede til ægte bevægelse — kameraet driver og skubber gennem scenen, parallakse og det hele, opfundet af modellen frem for forvrænget geometrisk.</p> </p> At seede SVD fra RealVisXL-stillsene giver genereret bevægelse, der stadig ligner turen. De ærlige forbehold: klippene er korte (~2–3 sekunder ved 25 frames), bevægelsen er kun løst styrbar (du nudger den med en “motion bucket”, ikke en bane), og der er let kant-forvrængning. Det er også det tungeste her — modellen fylder ~9 GB og passer på et 12 GB-kort kun med CPU-offload, UNet forward-chunking og en lille VAE-decode-chunk:</p> pipe.enable_model_cpu_offload() pipe.unet.enable_forward_chunking() frames = pipe(image, num_frames=25, decode_chunk_size=2, motion_bucket_id=110, noise_aug_strength=0.04).frames[0] </code></pre> 5. Filmisk slowmotion — rigtigt materiale, ingen AI</h2> Den femte mulighed bruger slet ingen generativ model. Tag de auto-minede øjeblikke, sæt dem ned til 50 % fart med bevægelseskompenseret optisk-flow-interpolation</strong> (så slowmotion bliver glat, ikke hakkende duplikerede frames), stabilisér let, og læg en filmisk grade på. ffmpeg klarer det i én filterkæde:</p> minterpolate=mi_mode=mci:mc_mode=aobmc:me_mode=bidir:vsbmc=1:fps=60,setpts=2.0PTS </code></pre> Det er 100 % ægte, ser dyrt ud og er det mest “broadcast” af det hele. Interpolation kan udtvære meget hurtige kanter, men på naturklip er det rent.</p> Hvilken vinder?</h2> Ingen — de supplerer hinanden, og en rigtig redigering blander flere:</p> Metode</th> Ægthed</th> Kontrol</th> Omkostning</th> Bedst til</th></tr></thead> 1 · Auto-mine (CV)</td> Ægte</td> Begrænset til det filmede</td> Øjeblikkelig</td> Ægte cutaways, gratis</td></tr> 2 · Generative stills (RealVisXL)</td> Syntetisk</td> Høj (enhver scene)</td> Mellem (GPU)</td> Shots du aldrig filmede</td></tr> 3 · Dybde-parallakse</td> Ægte + fake bevægelse</td> Kun bevægelse</td> Billig</td> At gøre et godt frame levende</td></tr> 4 · SVD-video</td> Syntetisk</td> Løs bevægelse</td> Tungest (~9 GB)</td> Levende bevægelse uden materiale</td></tr> 5 · Slowmotion (ægte)</td> 100 % ægte</td> Fart/grade</td> Mellem</td> Et dyrt klip af ægte øjeblikke</td></tr> </tbody></table> Hvis jeg skulle levere ét b-roll-lag til den slags materiale, blev det slowmotion (5) for den ægte, dyre følelse</strong>, med dybde-parallakse (3)</strong> til at lægge bevægelse på fremtrædende frames, og RealVisXL-stills (2)</strong> kun dér, hvor jeg har brug for et etableringsbillede, der aldrig kunne filmes.</p> Stak</h2> GPU:</strong> ét RTX 4070 Ti, 12 GB</strong>. Alt nedenstående passer.</li> Diffusion:</strong> diffusers</code> 0.38 — SDXL-base, RealVisXL V4.0</strong>, ControlNet-Canny-SDXL, Stable Video Diffusion XT</strong>.</li> Dybde:</strong> transformers</code> + Depth-Anything-V2-Small</strong>.</li> CV / samling:</strong> OpenCV, NumPy og ffmpeg</strong> (minterpolate</code>, deshake</code>, AV1 NVENC, AVIF-stills).</li> Et par fælder værd at huske: en distro-Python markeret PEP 668 externally-managed</strong> vil stille</em> nægte pip install</code> — brug et rigtigt virtualenv. Og pgrep -f build.sh</code> matcher glad og gerne den watcher-kommando</em>, der indeholder strengen, så stol ikke på den til at fortælle dig, at en rendering er færdig; tjek efter en levende ffmpeg</code> i stedet.</li> </ul> Hvorfor det findes</h2> Det startede som “onboard-klippene mangler cutaways, og jeg har ét kamera”. Det ærlige svar viste sig at være, at du ikke behøver et andet kamera — du skal finde</em> den b-roll, du allerede har filmet (1, 5), og fabrikere</em> resten med den mindste model, der gør arbejdet (3 før 2 før 4). Den mest prangende mulighed (generativ video) er den, jeg ville gribe til sidst. Den mindst prangende (at score frames med en Laplacian) er den, jeg ville gribe først.</p> Alt lokalt, alt på et kort, der koster mindre end en weekend med cloud-GPU. Ikke interessant før du har brug for det — og så er det præcis det, du har brug for.</p> Sammensætning af drone-panoramaer: OpenCV vs Hugin, benchmarket 2026-05-31T00:00:00+00:00 TL;DR —</strong> Jeg havde en mappe med 63 DJI Phantom 4 Pro-billeder taget over Randers og ville lave panoramaer ud af dem. Jeg sammensatte de samme sweeps på to måder: OpenCVs Stitcher</code></strong> (fuldautomatisk, sfærisk) og Hugins kommandolinje-pipeline</strong> (cpfind</code> → autooptimiser</code> → nona</code> → enblend</code>). OpenCV er hurtig (få sekunder) og beholder det bredeste synsfelt, men horisonten bliver bølget, kanterne flossede, og eksponeringssømmene er synlige. Hugin tager ~30 s pr. panorama, men giver en lige horisont, sømløs multi-band-overgang og et rent rektangulært beskåret billede</strong>. Til alt, du vil printe eller udgive, vinder Hugin. Alle kommandoer og en benchmark-tabel nedenfor.</p> Udgangspunktet</h2> En mappe, 63 filer, DJI_0029.jpeg</code> til DJI_0091.jpeg</code>, ~15 MB hver, 5464 × 3070 px. Ingen flylog, ingen projektfil, og — som det viste sig — det meste af de brugbare metadata fjernet. Bare JPEG-filer og en enlig result.jpg</code> fra et tidligere forsøg.</p> Første opgave: finde ud af hvad disse billeder egentlig er</em>, før jeg beslutter, hvordan de skal sammensættes. Er det et nadir-kortlægningsgitter? Ét enkelt rotations-panorama? Flere separate sweeps? Hver af dem sammensætter man forskelligt.</p> At regne optagelsen ud fra metadata</h2> Ingen exiftool</code> på maskinen, så:</p> sudo apt-get install -y libimage-exiftool-perl imagemagick </code></pre> DJI skriver normalt gimbal-yaw/pitch/roll ind i et XMP-namespace, som ville fortælle mig præcis, hvordan kameraet pegede for hvert billede. Her var det fjernet — filerne var tydeligvis blevet re-eksporteret på et tidspunkt (hvilket også forklarer den root-ejede result.jpg</code>). Det, der overlevede, var GPS og tidsstempler:</p> exiftool -n -T -FileName -GPSLatitude -GPSLongitude -GPSAltitude \ -SubSecDateTimeOriginal DJI_.jpeg </code></pre> To ting sprang straks i øjnene.</p> Der var to sessioner, 90 minutter fra hinanden:</strong></p> 0029</code>–0054</code>, taget 09:01–09:15</li> 0055</code>–0091</code>, taget 10:31–10:36</li> </ul> Den anden session var en stak vandrette sweeps i stigende højde.</strong> GPS-positionen flyttede sig næsten ikke, mens højden steg i tydelige bånd — 169 m, så 221 m, så 240 m, så 269 m. Det er signaturen på en drone, der svæver på stedet og panorerer kameraet hen over horisonten i hver højde. Hvert højdebånd er ét panorama.</p> Et hurtigt kontaktark bekræftede det:</p> ls DJI_.jpeg | sed 's/.jpeg//' | xargs -P4 -I{} \ convert {}.jpeg -resize 260x -gravity South -background black \ -splice 0x16 -pointsize 13 -fill yellow -annotate +0+1 '{}' /tmp/thumbs/{}.png montage /tmp/thumbs/DJI_00{55..91}.png -tile 6x -geometry +3+3 /tmp/sheet.png </code></pre> Session ét viste sig at være blandet — billeder lige ned på en enkelt ejendom i forskellige højder (en lodret zoom-sekvens, ikke et panorama) plus nogle skrå nabolagsoptagelser. Så jeg fokuserede panoramaerne på session to’s sweeps, som tydeligvis var det, dronen var der for at fange.</p> De grupper, jeg endte med:</p> Gruppe</th> Billeder</th> Højde</th> Indhold</th></tr></thead> A</td> 0055–0065</td> ~169 m</td> Villakvarter, lav panorering</td></tr> B</td> 0066–0076</td> ~221 m</td> By</td></tr> C+D</td> 0077–0091</td> 240–269 m</td> Høj skyline</td></tr> </tbody></table> Teknik 1 — OpenCV Stitcher</h2> Vejen med mindst modstand. OpenCV leverer en Stitcher</code> på højt niveau, der klarer feature-detektion, matchning, bundle adjustment, warping og blending i ét kald.</p> pip install opencv-contrib-python numpy </code></pre> import cv2, glob imgs = [cv2.imread(f) for f in sorted(glob.glob("group_A/.jpg"))] stitcher = cv2.Stitcher_create(cv2.Stitcher_PANORAMA) # sfærisk model status, pano = stitcher.stitch(imgs) if status == cv2.Stitcher_OK: cv2.imwrite("A_opencv.jpg", pano) </code></pre> To tilstande er vigtige:</p> PANORAMA</code></strong> antager, at kameraet roterede om sit optiske centrum (sfærisk warp). Korrekt for disse svæv-og-panorer-sweeps.</li> SCANS</code></strong> antager en affin/translatorisk model (flatbed-scanninger, nadir-kortlægning). Jeg prøvede den for fuldstændighedens skyld; den er den forkerte model her og reducerede de fleste sweeps til to-tre billeder. Brug den ikke til roterende luftoptagelser.</li> </ul> Jeg kørte alt på et 2400 px-arbejdssæt først — fuld opløsning er langsom at iterere på, og man vil gerne se, om en gruppe overhovedet hænger sammen, før man bruger minutter på den.</p> Dom over OpenCV:</strong> den bare virker, med nul parametre, på sekunder. Gruppe A — elleve billeder — blev til et 10433 × 1595-panorama på cirka 5 sekunder. Hagen er resultatet: en bølget horisont</strong>, flossede revne kanter</strong>, man selv skal beskære, og svage eksponeringssømme</strong>, hvor billeder mødes. Fint til et hurtigt kig; ikke noget, man printer.</p> Teknik 2 — Hugin-pipelinen</h2> Hugin</a> er open source-panoramaværktøjet, og afgørende er hele dets motor scriptbar fra kommandolinjen — ingen GUI nødvendig.</p> sudo apt-get install -y hugin-tools enblend enfuse </code></pre> Pipelinen, trin for trin:</p> pto_gen -o p.pto DJI_0055.jpeg ... DJI_0065.jpeg # 1. projekt fra EXIF cpfind --multirow -o p.pto p.pto # 2. find kontrolpunkter cpclean -o p.pto p.pto # 3. fjern dårlige matches autooptimiser -a -m -l -s -o p.pto p.pto # 4. optimér + ret horisont pano_modify --canvas=AUTO --crop=AUTO --projection=2 \ -o p.pto p.pto # 5. cylindrisk + auto-beskær nona -m TIFF_m -z LZW -o remap p.pto # 6. remap hvert billede enblend -o pano.tif remap.tif # 7. multi-band-overgang </code></pre> Hvad hvert trin giver dig ud over OpenCV-onelineren:</p> cpfind --multirow</code></strong> finder ordentlige kontrolpunkter på tværs af hele sættet — den rapporterede 250, 302 og 718 punkter for gruppe A, B og C+D.</li> autooptimiser -l -s</code></strong> retter horisonten og opretter panoramaet. Det er den største synlige gevinst: bølgen forsvinder.</li> --projection=2</code></strong> er cylindrisk, hvilket holder horisonten som en lige vandret linje — præcis hvad man vil have til et bredt luft-sweep.</li> --crop=AUTO</code></strong> beskærer til det største rene rektangel, så ingen manuel beskæring.</li> enblend</code></strong> laver multi-band (Burt–Adelson)-blending, som skjuler de eksponeringsforskelle mellem billeder, OpenCV efterlod synlige.</li> </ul> Samme gruppe, to pipelines, stablet — OpenCV øverst, Hugin nederst:</p> </p> Forskellen er ikke subtil.</p> Benchmarken</h2> Samme inputgrupper, begge pipelines. OpenCV-tallene er 2400 px-arbejdssættet; Hugin-tallene er de endelige kørsler i fuld opløsning på 5464 px.</p> Gruppe</th> Billeder</th> Værktøj</th> Resultat</th> Tid</th> Horisont</th> Overgang</th> Beskæring</th></tr></thead> A · villakvarter</td> 11</td> OpenCV PANORAMA</td> 10433 × 1595</td> 5 s</td> bølget</td> sømme</td> flosset</td></tr> A · villakvarter</td> 11</td> Hugin + enblend</strong></td> 11581 × 1827</td> 31 s</td> lige</strong></td> sømløs</strong></td> ren</strong></td></tr> B · by</td> 11</td> OpenCV PANORAMA</td> 10295 × 1838</td> 11 s</td> bølget</td> sømme</td> flosset</td></tr> B · by</td> 11</td> Hugin + enblend</strong></td> 8190 × 2547</td> 30 s</td> lige</strong></td> sømløs</strong></td> ren</strong></td></tr> C+D · skyline</td> 15</td> OpenCV PANORAMA</td> 8660 × 1975</td> 2 s</td> bølget</td> sømme</td> flosset</td></tr> C+D · skyline</td> 15</td> Hugin + enblend</strong></td> 22469 × 2391</td> 60 s</td> lige</strong></td> sømløs</strong></td> ren</strong></td></tr> </tbody></table> OpenCV er 3–10× hurtigere og beholder typisk et bredere synsfelt (den warper og beholder de revne kanter i stedet for at beskære dem). Hugin er langsommere, men vinder på hver kvalitetsakse, der betyder noget for et færdigt billede.</p> Op i fuld opløsning</h2> Da Hugin var den klare vinder, kørte jeg den igen på de originale 5464 px-billeder. Pipelinen er identisk — peg bare pto_gen</code> på de originale JPEG-filer i stedet for det nedskalerede sæt. cpfind</code> og enblend</code> er de langsomme trin ved fuld opløsning, men det lå stadig omkring 30 s pr. panorama, et minut for skyline-billedet med 15 frames.</p> De færdige panoramaer:</p> Den høje skyline — femten billeder, 22469 × 2391, et næsten 180° sweep hen over hele byen:</strong></p> </p> Villakvarter-sweepet i 169 m:</strong></p> </p> Byen i 221 m:</strong></p> </p> Ved 22469 px bredde kan skyline-billedet uden problemer printes i storformat.</p> FAQ</h2> Hvorfor betød metadataene så meget — hvorfor ikke bare smide alle 63 ind i stitcheren?</h3> Det kan man godt, og OpenCV vil forsøge at finde sammenhængende komponenter. Men filerne var to urelaterede sessioner plus en blanding af nadir- og skråbilleder. At fodre det hele ind risikerer, at optimeringen forbinder billeder, der ikke bør hænge sammen, eller spilder minutter på at fejle. Fem minutter med exiftool</code> til at gruppere billederne først sparede en masse gætteri — og fortalte mig, hvilke</em> grupper der overhovedet var panoramaer.</p> Hvorfor ikke bare bruge dronens indbyggede panorama-funktion?</h3> Disse var ikke taget som in-camera-panoramaer — det er enkeltbilleder fra manuelle sweeps, og den indbyggede sammensætning (hvis den overhovedet kørte) er den lavopløselige result.jpg</code>, jeg fandt i mappen. At sammensætte fra de originale fuldopløselige billeder giver langt mere detalje end in-camera-JPEG’en.</p> Hvad med PTGui / Lightroom / Microsoft ICE?</h3> Alle dygtige. PTGui er i bund og grund kommerciel Hugin og fremragende. Lightrooms Photo Merge er praktisk, hvis du allerede er derinde. Microsoft ICE var god, men er udgået. Jeg ville have en scriptbar, gratis, Linux-native pipeline, jeg kunne køre headless over en mappe — det er Hugin.</p> Cylindrisk, sfærisk eller rektilineær?</h3> Til et bredt vandret sweep holder cylindrisk</strong> (--projection=2</code>) horisonten lige og håndterer >120° uden den ekstreme strækning, rektilineær giver i kanterne. Sfærisk (det OpenCVs PANORAMA</code> bruger) er også fint, men har tendens til at bue horisonten, medmindre pitchen er godt estimeret — hvilket er sværere her, fordi gimbal-vinklerne var fjernet.</p> Kan det køre uovervåget over en hel mappe?</h3> Ja — hele Hugin-vejen er CLI, så den passer direkte ind i et shell-script eller en Makefile</code>. Gruppér billederne (efter tidsstempel/højde, eller lad bare cpfind</code> finde sammenhængende komponenter), og loop så de syv kommandoer pr. gruppe. Det er det egentlige argument for Hugin frem for et GUI-værktøj her.</p> Dom</h2> Vil du have et panorama nu</em> og er ligeglad med en bølget horisont eller selv at trimme kanter, er OpenCVs Stitcher</code> en fem-sekunders oneliner og oprigtigt imponerende for indsatsen.</p> Til alt, du beholder — print, udgivelse, på væggen — er Hugins kommandolinje-pipeline</strong> det ekstra halve minut værd. En lige horisont, en sømløs overgang og en automatisk ren beskæring er præcis de ting, der adskiller et snapshot fra et færdigt panorama, og Hugin leverer alle tre gratis. Det er nu mit standardvalg til at sammensætte alt fra dronen.</p> Det hele — fra installation til færdige fuldopløselige panoramaer — tog cirka en time, det meste brugt på at forstå billederne frem for at sammensætte dem. Hvilket som regel er sådan, det går.</p> bchunk — konverter .bin/.cue-images til .iso og .wav på Linux og macOS 2026-04-22T00:00:00+00:00 TL;DR —</strong> bchunk</code></strong> — også kaldet binchunker</code></strong> — er et lille, gammelt Unix-kommandolinjeværktøj, der tager et .bin</code>/.cue</code>-par (et råt cd-image med et cue-sheet) og deler det op i en rigtig .iso</code>-fil til datasporet</strong> og én .wav</code>-fil pr. lydspor</strong>. Det er det rigtige værktøj, når et download eller arkiv har givet dig game.bin</code> + game.cue</code>, og du faktisk vil mounte datasporet</strong> eller brænde lydsporene</strong> igen. Installeres med apt install bchunk</code> på Debian/Ubuntu, brew install bchunk</code> på macOS eller bygges fra kilden på alt andet. Brug er bchunk [options] image.bin image.cue basename</code> — du får basename01.iso</code>, basename02.wav</code>, basename03.wav</code> osv.</p> Hvad .bin/.cue er, og hvorfor du vil splitte det</h2> Et .bin</code>/.cue</code>-par er et råt, bit-nøjagtigt cd-image</strong> plus et klartekst-sheet, der beskriver sporenes layout. .bin</code> indeholder hver sektor af cd’en i rækkefølge — inklusive datasport (Mode 1 eller Mode 2), lydspor (rå Red Book PCM, 2352 bytes pr. sektor, intet filsystem) og pauserne imellem dem. .cue</code> fortæller, hvor hvert spor begynder, og hvilken type det er.</p> Formatet er standard-output for cd-ripning-værktøjer som cdrdao og for gamle spil-arkiver, fordi det bevarer alt</em> — pregaps, CD-TEXT, mixed-mode-cd’er, CD-DA-lyd. Det er også grunden til, at du ikke bare kan omdøbe game.bin</code> til game.iso</code> og mounte det: en mixed-mode-cd har ikke-filsystem-sektorer</strong> i starten, lydspor der slet ikke er filsystem, og per-sektor-headers, som ISO forventer fjernet.</p> bchunk</code> laver konverteringen rigtigt:</p> Datasport</strong> bliver til ISO 9660-filer (.iso</code>) — 2352-byte cd-sektorer bliver trimmet til 2048-byte ISO-sektorer, headers smidt væk.</li> Lydspor</strong> bliver til 16-bit stereo 44,1 kHz .wav</code>-filer, hver med en ordentlig WAV-header.</li> </ul> Derefter kan du mount -o loop</code> .iso</code>’en, afspille .wav</code>’erne eller fodre dem til en brænder.</p> Installation</h2> Debian / Ubuntu / Mint</h3> sudo apt install bchunk </code></pre> macOS (Homebrew)</h3> brew install bchunk </code></pre> Arch / Manjaro</h3> sudo pacman -S bchunk # eller fra AUR: yay -S bchunk </code></pre> Fedora / RHEL / CentOS</h3> bchunk</code> er ikke i standard-repoet; hent det fra RPMFusion eller byg fra kilden:</p> git clone https://github.com/hessu/bchunk.git cd bchunk make sudo cp bchunk /usr/local/bin/ </code></pre> Windows</h3> Brug WSL og apt install bchunk</code>. Der findes en gammel native port, men WSL er nemmere.</p> Grundlæggende brug</h2> bchunk game.bin game.cue game </code></pre> Output:</p> game01.iso # datasport, mountbart som ISO 9660 game02.wav # lydspor 1 game03.wav # lydspor 2 ... </code></pre> basename</code> (game</code> i eksemplet) er præfikset for hver output-fil. Spornumre starter ved 01</code>.</p> Nyttige options</h2> bchunk</code> har et lille, stabilt sæt flag — de fleste er der for at håndtere specifikke cd-særheder.</p> -v</code></strong> — verbose. Printer hvert spor, efterhånden som det behandles. Brug den første gang, du kører det, for at bekræfte, at du får det sporlayout, du forventer.</li> -w</code></strong> — skriv .wav</code>-filer (default). Eksplicit form.</li> -r</code></strong> — rå lydoutput i stedet for .wav</code>. Nyttigt hvis du piper ind i sox</code> eller ffmpeg</code> og ikke vil have et ekstra header-skrællende skridt.</li> -p</code></strong> — Psx/PlayStation-mode</strong>. Behandler Mode 2-sektorer mere løst — nødvendigt for mange PlayStation-cd-images, hvor cue-sheetet er upræcist.</li> -s</code></strong> — byt byte-rækkefølge på lydspor. Nødvendigt hvis .bin</code>’en er produceret af en ripper, der skrev little-endian-lyd, hvor bchunk</code> forventer big-endian (eller omvendt). Symptom: output-.wav</code> lyder som hvid støj.</li> -W</code></strong> — skriv .wav</code> med en verificeret (i stedet for beregnet) header-størrelse. Sjældent nødvendigt.</li> -E</code></strong> — brug de nøjagtige spor-grænser fra cue-sheetet i stedet for at prøve sig frem. Brug dette hvis lydspor lyder klippet i starten eller slutningen.</li> </ul> Mount af den resulterende .iso</h2> På Linux:</p> sudo mkdir /mnt/cd sudo mount -o loop game01.iso /mnt/cd ls /mnt/cd </code></pre> På macOS:</p> hdiutil attach game01.iso </code></pre> Almindelige faldgruber</h2> “Illegal or unsupported track type” eller tomt output</h3> Dit cue-sheet er malformet eller refererer til en .bin</code>-størrelse, der ikke matcher. Åbn .cue</code>’en i en teksteditor — den er klartekst — og tjek:</p> FILE "..."</code>-linjen peger på det rigtige .bin</code>-filnavn, case-sensitivt.</li> TRACK</code>-entries er nummereret sekventielt med typerne MODE1/2352</code>, MODE2/2352</code> eller AUDIO</code>.</li> Index-entries (INDEX 00</code>, INDEX 01</code>) er MM:SS:FF, hvor FF er frames (0–74).</li> </ul> Lydspor lyder som statisk</h3> Byte-rækkefølge-mismatch. Prøv igen med -s</code>:</p> bchunk -s game.bin game.cue game </code></pre> Enkelt .iso</code> er fin, men lydspor er stille eller afkortede</h3> Prøv -E</code> for at tvinge cue-sheet-eksakte grænser:</p> bchunk -E game.bin game.cue game </code></pre> PlayStation/PSX-image splitter ikke rent</h3> Brug -p</code>:</p> bchunk -p psx.bin psx.cue psx </code></pre> Det er den mest almindelige klage på fora — PSX-cues er næsten altid Mode 2, og bchunk</code> uden -p</code> er streng overfor dem.</p> Flere .bin</code>-filer refereret i cue-sheetet</h3> Nogle rippere producerer én .bin</code> pr. spor plus et samlende cue-sheet. bchunk</code> forventer én .bin</code> for hele skiven. Concatener dem først med cat track01.bin track02.bin ... > combined.bin</code> og peg et single-file-cue på combined.bin</code>.</p> Alternativer værd at kende</h2> cdemu</code></strong> — user-space cd-emulator til Linux. Kan mounte en .bin</code>/.cue</code> direkte uden at splitte. Nyttigt, hvis du bare vil læse</em> datasporet midlertidigt.</li> ecm-tools</code></strong> — andet format (.ecm</code>), men samme problemområde. Værd at kende, hvis du støder på det.</li> 7z</code> / p7zip</code></strong> — nyere 7-Zip-versioner kan liste og uddrage ISO 9660-datasport fra en rå .bin</code>, men kan ikke redde lyd som .wav</code>.</li> ffmpeg</code></strong> — hvis du vil have MP3 / FLAC / Opus i stedet for .wav</code>, pipe rå-outputtet: bchunk -r game.bin game.cue game && ffmpeg -f s16be -ar 44100 -ac 2 -i game02.raw game02.flac</code>.</li> </ul> Hvorfor det stadig er nyttigt i 2026</h2> Optisk-medie-imaging har været et løst problem i årtier, men .bin</code>/.cue</code> er stadig default-output fra cdrdao</code>, stadig det gamle arkiver er lagret som, og stadig det, der dukker op, når nogen rækker dig en cd-backup, der ikke er en ISO. bchunk</code> er et ~1.000-liniers C-program, skrevet i sen-1990’erne, der gør ét job korrekt og knap har ændret sig i tyve år. Det er i alle store distributioner, det kompilerer rent på moderne systemer, og det er det rigtige værktøj.</p> Hvis du prøver at redde data fra et gammelt cd-image: start her.</p> binlist.net — hvordan et ferie-sideprojekt fra Fuerteventura blev til iinlist.com 2026-04-22T00:00:00+00:00 TL;DR —</strong> binlist.net</a> er en gratis HTTP-API</strong>, der tager de første 6–8 cifre af et kortnummer (BIN</strong> eller IIN</strong>) og returnerer udsteder-bank, land, kort-netværk (Visa, Mastercard osv.), korttype (debit/credit/prepaid) og kategori. Jeg startede den i august 2013 på ferie på Fuerteventura</strong>, fordi jeg skulle bruge BIN-opslag til et andet projekt, og alt der fandtes var enten betalingspligtigt, forældet eller bag en tvivlsom scraper. Det var mit første Go-projekt nogensinde</strong>, ramte 100.000 queries/dag</strong> inden for uger og krydsede 1 million queries/dag i 2015</strong>. Den er stadig online, stadig gratis, stadig curl</code>-venlig. Den kommercielle variant, iinlist.com</a>, er den, jeg medstiftede efter binlist.nets succes; det er samme idé med betalingsindustri-præcision</strong>, 8-cifret IIN-understøttelse</strong> (påkrævet af ISO/IEC 7812 siden 2022), ARDEF-baserede ranges</strong> og en SLA — bygget til banker, PSP’er, fraud-teams og issuere, der har brug for at behandle BIN-data som produktions-data.</p> BIN vs IIN — et grundkursus på én paragraf</h2> De første seks (historisk) eller otte (siden 2017, obligatorisk fra 2022) cifre af et kortnummer er Issuer Identification Number</strong> (IIN). Det gamle navn, stadig vidt brugt, er Bank Identification Number</strong> (BIN). Givet en BIN/IIN kan du afgøre:</p> Netværk</strong> — Visa, Mastercard, Amex, Discover, JCB, UnionPay, Diners.</li> Udsteder</strong> — banken eller fintech’en, der udstedte kortet.</li> Land</strong> — udstederens land, ikke nødvendigvis kortholderens, men en nyttig proxy for risiko-scoring, skatte-logik (EU/EØS moms-OSS) og brugeroplevelse (foretrukket sprog, lokale betalingsmetoder).</li> Type</strong> — debit, credit, prepaid, deferred debit, charge.</li> Kategori / produkt</strong> — Classic, Gold, Platinum, Business, Corporate osv. Nyttigt til acceptance-cost-routing (erhvervskort koster mere at modtage).</li> </ul> Alt dette er “følsomt” i den forstand, at udstedere ikke offentliggør fulde BIN-tabeller, og kort-netværkene betragter dem som proprietære. I praksis lækker BIN-ranges konstant — hver autorisation, netværket router, hver chargeback-dispute — og der er en hel bibranche omkring at holde rimeligt præcise BIN-tabeller.</p> Hvorfor jeg byggede binlist.net på ferie</h2> Sommer 2013. Playitas, sydlige Fuerteventura</strong> — resortet på Atlanterhavs-siden nede ved Gran Tarajal. Lejet lejlighed, lille balkon, kanariefuglevinden gør sit. Jeg havde en idé til et sideprojekt, der skulle slå kort op via BIN, og jeg ville ikke betale en betalings-leverandør €200/md for det. De eksisterende gratis muligheder var:</p> Wikipedias IIN-liste</strong> — rimelig præcis for velkendte netværk, elendig dækning for niche-udstedere, opdateret af frivillige, der ikke arbejder i payments.</li> Indsatte CSV’er på fora</strong> — anstændig dækning for US-udstedere, altid forældet.</li> Google Fusion Tables</strong> — udfaset af Google samme år.</li> Scrapere af merchant-bankers opslagsformer</strong> — ToS-overtrædende, skrøbelige.</li> </ul> Det jeg ville have, var curl http://example.com/40012345</code> der returnerer ren JSON. Så jeg byggede det.</p> Stakken (dengang)</h3> Det var mit første Go-projekt nogensinde</strong>. Jeg havde læst om Go et stykke tid og ville have en lille, velafgrænset undskyldning for at prøve det; en single-endpoint JSON-API over en in-memory BIN-tabel var perfekt. Ruby/Sinatra ville have været hurtigere at taste for mig, men jeg ville lære noget, og memory- og latency-karakteristikken af en Go-binary viste sig at være præcis det, en gratis-tier offentlig API havde brug for.</p> Go</strong> — en enkelt binary, net/http</code>, ingen framework. Hele serveren fyldte nogle hundrede linjer.</li> In-memory BIN-range-tabel</strong>, bygget ved boot fra en ~300 MB kilde-fil. Opslag var O(log n) over et sorteret slice.</li> Deployet på én Hetzner-VM</strong> fra dag ét (jeg overvejede kortvarigt Heroku, men Heroku’s gratis dyno-memory-grænser kunne ikke rumme en fuldt indlæst BIN-tabel).</li> JSON + XML + CSV</strong>-svarformater, fordi 2013.</li> Dataseed</strong> fra en kombination af offentlige Wikipedia-scrapes, den gamle “Mars Base”-CSV fra 2009 og et sæt ranges, jeg havde akkumuleret på arbejde.</li> </ul> Samlet build-tid på den balkon: en weekend — hvoraf cirka halvdelen var mig, der fandt ud af go build</code>, GOPATH</code> (Go-moduler fandtes ikke endnu) og hvordan interfaces virkede. Jeg købte domænet mandag morgen, deployede binaryen og tweetede om det.</p> Trafik-kurven</h3> Uge 1:</strong> et par hundrede queries/dag, mest mig, der testede.</li> Måned 1:</strong> ~100.000 queries/dag</strong>, efter udviklere på Stack Overflow og et par e-handels-fora fandt den.</li> I begyndelsen af 2015:</strong> krydsede 1 million queries/dag</strong> vedholdende, med spikes over 2M under flash-sale-events hos merchants, der kaldte den på hver checkout-page-load.</li> </ul> At skalere til det punkt kostede næsten ingenting, fordi Go’s single-binary-fodaftryk betød, at en ~€5/md VPS klarede det hele; flaskehalsen var længe NIC’en, ikke CPU eller memory.</p> 13 år senere</h3> binlist.net kører stadig. Den er blevet flyttet infrastruktur nogle gange — Hetzner-VM → Hetzner-flåde → en lille flåde bag Cloudflare — og dataseed’et er blevet opdateret løbende, men API-overfladen (og det meste af den oprindelige Go-kode) er den samme. I dag serverer den titusinder af millioner opslag pr. måned</strong>, gratis, uden API-nøgle, med en soft-rate-limit på anonyme kaldere for at holde den ærlig.</p> Den har ~2.000 Google-visninger/md</strong> for queries som “binlist”, “bin list bank identification number”, “list of bank identification numbers” — den samler stadig den lange hale af udviklere op, der skriver samme spørgsmål, jeg skrev i Google i 2013.</p> Hvorfor iinlist.com findes</h2> binlist.nets data er god nok til “hvilket land er dette kort fra”-beslutninger — risiko-scoring, valuta-præsentation, analytics. Den er ikke</strong> god nok til:</p> Acceptance-cost-routing</strong>, hvor du router erhvervskorts-transaktioner gennem en anden processor.</li> Interchange++-modellering</strong>, hvor margin-forskellen mellem Classic og Platinum Mastercard er rigtige penge.</li> Compliance</strong> — ISO/IEC 7812-migrationen fra 6-cifrede BIN’er til 8-cifrede IIN’er, obligatorisk fra 2022, brød en masse “jeg bruger bare de første seks cifre”-logik.</li> Co-badged kort</strong> (f.eks. Dankort + Visa Debit), hvor to netværk begge hævder kortet, og routing-beslutningen er forretningskritisk.</li> ARDEF-præcision</strong> — Visas Account Range Definition File er sandhedskilden; du vil virkelig have data afledt af ARDEF til noget, der kører i produktion.</li> </ul> iinlist.com løser det, kommercielt. Jeg medstiftede den med et lille team af folk, der kender payments-data professionelt. Det er produktet, som binlist.net er gratis-tier-annoncen for. Nogle af vores kunder er navne, du ville genkende; de fleste er ikke. De kommer alle til samme konklusion: BIN-data der er “stort set rigtige” koster mere i forkerte beslutninger, end præcise data koster i licens-gebyr</strong>.</p> Hvad iinlist.com specifikt er</h3> 8-cifret IIN-understøttelse</strong> på tværs af alle netværk.</li> Daglige opdateringer</strong> afledt af ARDEF + netværks-feeds + udsteder-annonceringer + intern verificering.</li> Rigere enrichment</strong>: korttype, produkt-kategori, udsteder-land, udsteder-branding, regulatoriske klassifikationer (commercial vs consumer, prepaid-flag osv.).</li> SLA og support</strong>. Du kan oprette en ticket, og den når faktisk et menneske.</li> On-prem / self-hosted</strong>-mulighed for kunder, hvis compliance ikke tillader “BIN-opslag som tredjeparts-API-kald i autorisations-stien”.</li> Prissætning</strong> der giver mening for både en startende fintech (månedlig plan) og en etableret acquirer (årlig, ubegrænset).</li> </ul> Kan jeg bare bruge binlist.net kommercielt?</h2> Du kan bruge binlist.net, som du vil; der er ingen gate. Men:</p> Ingen SLA, ingen oppetidsgaranti, ingen kontrakt. Det er et sideprojekt, der er blevet oppe i 13 år.</li> Rate-limits på anonym trafik træder i kraft ved produktions-volumen. Køb en licens fra iinlist.com, og problemet er løst.</li> Hvis din regulator spørger, hvor dine BIN-data kommer fra, er “en gratis API, min udvikler fandt” ikke det svar, du vil give.</li> </ul> Til hobby, demo eller prototype: binlist.net er perfekt. Til alt, hvor forkerte BIN-data bliver en KPI: iinlist.com.</p> Brug af binlist.net i dag</h2> $ curl -sH "Accept-Version: 3" https://lookup.binlist.net/45717360 { "number": { "length": 16, "luhn": true }, "scheme": "visa", "type": "debit", "brand": "Visa/Dankort", "country": { "numeric": "208", "alpha2": "DK", "name": "Denmark", "emoji": "🇩🇰", "currency": "DKK", "latitude": 56, "longitude": 10 }, "bank": { "name": "Jyske Bank A/S", "url": "www.jyskebank.dk", "phone": "+4589893300", "city": "Silkeborg" } } </code></pre> Accept-Version: 3</code></strong> — pin’er til API v3.</li> Anonym rate-limit</strong> — dokumenteret på siden, rigeligt til almindelig brug.</li> Ingen garantier</strong> — hvis svaret er forkert, indsend en rettelse på GitHub-repoet. Til kommercielle garantier: se iinlist.com.</li> </ul> Ofte stillede spørgsmål</h2> Er BIN-/IIN-data reguleret?</h3> BIN-ranges i sig selv er ikke persondata under GDPR — en BIN identificerer en udsteder, ikke en person. Kombination af en BIN med et fuldt kortnummer er en anden historie og falder under PCI-DSS.</p> Hvad ændrede sig med 8-cifret IIN-migrationen?</h3> ISO/IEC 7812 formaliserede 8-cifrede IIN’er i 2017 med en hård migrations-deadline i april 2022 for de store netværk. Hvis din kode stadig behandler kun de første seks cifre som udsteder-identifikatoren, fejlrouter du lydløst en voksende del af din trafik — moderne Visa- og Mastercard-udsteder-ranges er defineret ved 8 cifre.</p> Hvorfor ikke bare slå op på klient-siden?</h3> Det kan du, med en statisk liste i browseren. Men du accepterer et trade-off: friskhed (den statiske liste er forældet inden for uger) eller bundle-størrelse (den nuværende BIN-tabel er megabytes ukomprimeret). En server-side-API er det konventionelle svar.</p> Logger binlist.net de BIN’er, jeg slår op?</h3> Kun aggregeret analytics — nok til at opdage misbrug og rate-limite. Enkelte opslag er ikke knyttet til en bruger. iinlist.com har en strammere no-logging-holdning til kunder, hvor det betyder noget.</p> Er kildekoden open source?</h3> API-overfladen af binlist.net er på GitHub med retningslinjer for data-rettelser. Data-ingestion-pipelinen er ikke open source; den afhænger af netværks-feeds, der kræver licenser.</p> Er binlist.net og iinlist.com samme firma?</h3> Adskilte projekter, overlappende oprindelse, samme operatør på min side. binlist.net er en personlig gratis-tjeneste; iinlist.com er et kommercielt selskab med medstiftere og medarbejdere. De to er driftsmæssigt uafhængige, men deler institutionel viden om BIN-data, som ikke er nem at akkumulere fra bunden.</p> Tretten år inde</h2> Det, jeg finder mest interessant ved binlist.net, er ikke trafikken — det er den slags spørgsmål</strong>, udviklere stadig skriver ind i Google i 2026: “what is a bin list”, “bin number example”, “list of issuer identification numbers”. Det er nøjagtig de queries, jeg skrev i 2013 på balkonen i Playitas. Payments som industri fortsætter med at tilføje lag, men de grundlæggende spørgsmål ændrer sig ikke.</p> Hvis du sidder på en strand med en laptop, og du har en kløe til et sideprojekt, der klør din egen ryg: byg det — og prøv imens det sprog, du har haft lyst til at lære. Nogle gange viser det sig, at mange har samme kløe, og tretten år senere har du en nyttig ting at pege dem på og et arbejdende kendskab til Go.</p> Mit CM3588-projekt — 4-NVMe ARM64 hjemme-NAS på 10 W tomgang 2026-04-22T00:00:00+00:00 TL;DR —</strong> FriendlyElec CM3588 NAS Kit</a> er et RK3588-baseret compute-modul på en carrier-board med fire M.2 NVMe-pladser (PCIe 3.0 x1 hver)</strong>, 2,5 GbE</strong>, 2× HDMI ud</strong>, USB 3.0</strong> og en 8-kernet ARMv8-CPU (4× Cortex-A76 + 4× Cortex-A55). Fuldt lastet med fire NVMe-drev går den i tomgang på ca. 10 W</strong>, peaker omkring 20 W under tung I/O, og læser/skriver en NVMe på ca. 1 GB/s (bus-grænsen, ikke drevet). Min egen kører Debian på mainline-kernel, med ZFS på root, fire 2 TB NVMe-drev i en raidz2</code>-pool, Samba til LAN-shares og Tailscale til adgang uden for LAN. Den har erstattet en tower-PC med TrueNAS og skåret NAS-strømforbruget med ca. 60 W.</p> Hvorfor netop dette board</h2> Jeg havde kørt en tower-PC som hjemme-NAS i årevis: en brugt desktop, seks 3,5“-harddiske og en støjende blæser. Det virkede, men den trak 70–80 W tomgang og stod i et skab, der skulle have aktiv udluftning. Harddiskene var højlydte nok til, at jeg havde flyttet dem til det fjerneste hjørne af huset.</p> Tre ting, jeg ville have af en afløser:</p> Kun NVMe.</strong> Roterende harddiske er billigere pr. terabyte, men støjen, vibrationen og varmen er ikke værd for et hjemme-NAS på nogle få terabyte. 4× 2 TB NVMe er rigeligt.</li> ARM, for strømforbrugets skyld.</strong> Et x86-board med 4× PCIe-pladser forbundet til NVMe ville trække 30–40 W tomgang. ARM kan klare det på 10.</li> Mainline Linux, ikke en leverandør-fork.</strong> Jeg vil have apt-get dist-upgrade</code> til at virke, zfs</code> til at bygge fra DKMS mod en nyere kernel og ingen tre år gammel vendor-BSP.</li> </ol> CM3588 NAS Kit rammer alle tre.</p> Hardware</h2> SoC:</strong> Rockchip RK3588 (4× Cortex-A76 @ 2,4 GHz + 4× Cortex-A55 @ 1,8 GHz, Mali-G610 GPU, 6 TOPS NPU). ARMv8.2-A.</li> RAM:</strong> 8 GB LPDDR4X på det modul, jeg købte. 16 GB- og 32 GB-varianter findes.</li> Lagring:</strong> 64 GB eMMC on-module til OS + 4× M.2 Key-M 2280-pladser, hver PCIe Gen 3 x1</strong> (altså ~1 GB/s pr. plads, ikke x4).</li> Netværk:</strong> 1× 2,5 GbE (Realtek RTL8125B).</li> USB:</strong> 2× USB 3.0 Type-A, 1× USB 3.0 Type-C (DisplayPort alt-mode), 1× USB 2.0.</li> Video:</strong> 2× HDMI ud, 1× HDMI ind</strong> (RK3588’s capture-blok).</li> Strøm:</strong> 12 V barrel-jack. Et 60 W-strømforsyning er mere end nok.</li> </ul> Boardet er lille — ca. 10 × 10 cm — og passivt over SoC’en plus en lille blæser, der blæser hen over NVMe-drevene. Mit står fladt på en hylde uden kabinet.</p> NVMe-kompatibilitetsadvarsel</h3> Den ene ting, der er værd at vide: CM3588 NAS Kit er ikke kompatibelt med visse WD Blue SN580- og WD Black SN850-drev</strong> — linket flapper ved boot. Jeg bruger Samsung 990 EVO og Crucial P3 Plus; begge virker fint. Tjek FriendlyElecs wiki-kompatibilitetsliste før du køber NVMe-drev.</p> OS og filsystem</h2> Jeg kører Debian 13 (trixie)</strong> med mainline-kernel</strong> — RK3588-understøttelse er god nok fra 6.8 og frem til headless-brug. FriendlyElecs Debian-image virker ud af boksen, men jeg geninstallerer ovenpå for at få et rent Debian i stedet for deres BSP.</p> Root-filsystem:</strong> ext4</code> på eMMC.</li> Datapool:</strong> zfs</code> raidz2</code> på tværs af de fire NVMe-drev. Med 4× 2 TB giver raidz2</code> ~3,5 TB brugbart med to-disks-redundans. Ja, raidz2</code> på fire drev er konservativt; det betyder også, at et dobbelt-svigt ikke spiser poolen, og på NVMe er rebuilden hurtig nok til, at jeg ikke mister nattesøvn over det.</li> ZFS-modul:</strong> DKMS mod den kørende kernel. Bygger automatisk ved kernel-opgraderinger. Har virket uden manuel indgriben på tværs af tre kernel-bumps.</li> ARC-tuning:</strong> Loftet ved 2 GB. Det giver headroom på et 8 GB-system.</li> </ul> Gennemløbet er flaskehals-begrænset af 2,5 GbE til netværks-I/O (~280 MB/s vedholdende), længe før ZFS eller NVMe-drevene kommer på arbejde. Lokale operationer på poolen når omkring 2 GB/s samlet sekventiel læsning.</p> Tjenester</h2> Bevidst holdt simpelt:</p> Samba</strong> til SMB-shares til Mac’erne og Windows-boksen på LAN’et.</li> rsync + cron</strong> til natlige backups fra tre andre maskiner.</li> ZFS-snapshots</strong> hver time, opbevares en uge. zfs send</code> piper datasættet ugentligt til en offsite B2-bucket via zfs-autobackup</code> + rclone.</li> Tailscale</strong> til adgang uden for LAN. Ingen port-forwarding, ingen dyndns, ingen VPN-koncentrator. SSH og Samba rider begge på Tailscale-interfacet, når jeg er væk.</li> Cockpit</strong> til det lejlighedsvise “hvorfor larmer blæseren” dashboard-øjeblik.</li> </ul> Det er alt. Ingen Docker swarm, ingen Kubernetes, ingen dusin sidecar-containere. Boardet har ét job — serve filer på LAN’et og lade mig trække backups offsite — og det gør det i stilhed.</p> Strøm og støj</h2> Tomgang</strong> (alle fire NVMe opspundne, ingen trafik): ~10 W</strong> ved stikkontakten.</li> Travlt</strong> (NVMe-læsning mætter 2,5 GbE, ZFS-ARC varm): ~18–20 W</strong>.</li> Peak</strong> (scrub af hele poolen, alle kerner varme): ~25 W</strong>.</li> </ul> Sammenlignet med den 70–80 W-tower, den afløste, er strøm-ROI’en alene omkring 500 kWh/år</strong>, eller cirka 1.500 kr/år</strong> ved danske privat-takster. Boardet betalte sig selv tilbage på ca. et år.</p> Støj: i praksis uhørlig fra mere end en meters afstand. Blæseren er lille, og 80 % af tiden kører den knap nok.</p> Hvad virkede ikke, eller tog arbejde</h2> Vendor-kernel.</strong> FriendlyElecs leverede kernel er deres fork af 6.1 med RK-specifikke patches. Det virker til deres nøglefærdige NAS-image, men DKMS-ZFS-builds er bøvlede mod den. Skiftet til mainline løste det.</li> HDMI-capture.</strong> RK3588 har en hardware HDMI-input-blok. I mainline er den stadig eksperimentel. Jeg har en vag brugscase for den (trække signal fra en gammel enhed til arkivering), men har ikke fået det til at virke end-to-end. Parkeret indtil videre.</li> NPU.</strong> De 6 TOPS NPU er underudnyttet. Mainline har basal RKNPU-understøttelse, men til noget praktisk skal du stadig bruge FriendlyElecs rknn-toolkit2</code>. Ikke et problem for et NAS.</li> </ul> Ofte stillede spørgsmål</h2> Hvorfor ikke x86?</h3> En x86-mini-PC med 4× NVMe er ~2× tomgangsstrømmen og ~2× købsprisen (når du tæller kabinet, PSU og CPU med). Til et hjemme-NAS, hvor arbejdsbyrden er “serve filer” snarere end “kør 40 containere”, vinder ARM.</p> Hvorfor ikke Raspberry Pi 5?</h3> Pi 5 har én PCIe 2.0 x1-lane eksponeret via en HAT — du kan bolte en NVMe på, men kun én, med loft ved ~500 MB/s. CM3588 har fire lanes ved PCIe 3.0 direkte forbundet. En anden klasse af board.</p> Hvorfor ikke OpenMediaVault eller TrueNAS?</h3> Begge ville virke. Jeg foretrækker rent Debian + Samba + ZFS, fordi opgraderingsstien for Debian er velkendt for mig, og OMV/TrueNAS er et lag, jeg skulle lære på ny. Det afhænger af dig.</p> Hvorfor raidz2</code> på fire drev og ikke mirror + mirror</code>?</h3> Overvejet. mirror + mirror</code> giver hurtigere skriv og lettere udvidelse, men kun 4 TB brugbart fra 4× 2 TB — det samme som raidz2</code>. Med raidz2</code> kan to vilkårlige drev svigte; med stripede mirrors kan du miste to drev, men kun hvis de er i forskellige mirror-par. På fire drev er kapaciteten identisk, og raidz2</code> har den stærkere fejltolerance.</p> Kan den køre Plex / Jellyfin?</h3> Ja, og RK3588’s hardware H.265/VP9/AV1-decode-blok klarer det tunge arbejde. Jellyfin med rkmpp</code>-accelereret decoding håndterer 4K HEVC-transcodes på omkring 3× realtid. Jeg kører ingen af delene på denne boks — min Plex bor et andet sted — men det er realistisk.</p> Går den i suspend?</h3> Ikke pålideligt. Lad den stå tændt; tomgang er alligevel 10 W.</p> Hvad med støj og varme om sommeren?</h3> Passivt køleplade plus en lille blæser. I en dansk sommer (20–25 °C i rummet) topper den omkring 55 °C die-temperatur under en ZFS-scrub. Ingen throttling målt.</p> Dom</h2> Hvis du vil have et lydsvagt, strømbesparende, ren-NVMe-hjemme-NAS med nok PCIe til at betyde noget</strong> og er villig til at bruge en aften på Debian + ZFS, er CM3588 NAS Kit den bedste mulighed, jeg har fundet. Det er ikke det billigste — en brugt Optiplex er billigere på forhånd — men på tre års TCO inkl. strøm betaler det sig tydeligt tilbage.</p> RK3588 i sig selv er en overraskende kapabel SoC til homelab-arbejdsbyrder. Da mainline-kernel-understøttelsen landede, holdt jeg op med at behandle den som “en ARM-kuriositet” og begyndte at behandle den som default-svar på små altid-tændte servere.</p> To år inde er min blevet genstartet to gange (en gang for en kernel-opgradering, en gang fordi jeg flyttede hylden). Jeg ville købe den igen.</p> pdfcrack — gendan glemte PDF-kodeord på Linux og macOS (2026) 2026-04-22T00:00:00+00:00 TL;DR —</strong> pdfcrack</code></strong> er et kommandolinjeværktøj, der gendanner user-kodeordet</strong> eller owner-kodeordet</strong> på en krypteret PDF via brute-force eller dictionary-angreb. Det er lille, skrevet i C, kører på Linux/macOS/WSL og håndterer enhver krypterings-profil, PDF har leveret — 40-bit RC4, 128-bit RC4, 128-bit AES, 256-bit AES (PDF 1.7 + 2.0). Det er single-threaded og kun CPU</strong>, så det er hurtigt på den svage gamle RC4-40-kryptering, men stadig langsommere, efterhånden som PDF’er bliver moderne. Installeres med apt install pdfcrack</code> (Debian/Ubuntu), brew install pdfcrack</code> (macOS) eller bygges fra kilden. Når pdfcrack</code> er for langsom, så skift til pdf2john</code> + hashcat</code></strong> på en GPU.</p> Dette indlæg antager, at du har autorisation til at gendanne kodeordet</strong> på PDF’en — dit eget dokument, en kundes eller en lovligt anskaffet fil. Angrib ikke PDF’er, du ikke ejer.</p> User-kodeord vs owner-kodeord</h2> PDF har to kodeord:</p> User-kodeord</strong> — kræves for at åbne og læse</strong> dokumentet.</li> Owner-kodeord</strong> — kræves for at fjerne begrænsninger</strong> (print, kopi, rediger) på et dokument, der åbner uden et user-kodeord.</li> </ul> Mange “beskyttede” PDF’er er kun owner-kodeord-begrænsede: de åbner fint, men print og kopi er deaktiveret af læseren. Dem er trivielt at låse op — qpdf --decrypt</code> eller et hvilket som helst pdftk</code>-lignende værktøj fjerner owner-only-restriktioner uden at skulle gætte noget. pdfcrack</code> er til det sværere tilfælde: en user-kodeord-beskyttet PDF, du slet ikke kan åbne</strong>.</p> Tjek hvilken du har med at gøre:</p> $ qpdf --show-encryption dokument.pdf R = 6 P = -3904 User password = Supplied password is owner password extract for accessibility: allowed extract for any purpose: not allowed print low resolution: allowed print high resolution: not allowed modify document assembly: not allowed modify forms: not allowed modify annotations: not allowed modify other: not allowed stream encryption method: AESv3 string encryption method: AESv3 file encryption method: AESv3 </code></pre> R = ...</code></strong> fortæller dig revisionen/profilen. R=2</code> = RC4-40, R=3</code> = RC4-128, R=4</code> = AES-128, R=5/6</code> = AES-256.</li> “Supplied password is owner password”</strong> + “User password = (tom)” betyder, du kan åbne den og bare skal fjerne restriktioner. Brug qpdf --decrypt --password='' input.pdf output.pdf</code>, og du er færdig.</li> </ul> Installation</h2> # Debian / Ubuntu / Mint / Kali sudo apt install pdfcrack # macOS (Homebrew) brew install pdfcrack # Arch / Manjaro sudo pacman -S pdfcrack # Fedora / RHEL sudo dnf install pdfcrack # Fra kilden wget https://sourceforge.net/projects/pdfcrack/files/latest/download -O pdfcrack.tar.gz tar xf pdfcrack.tar.gz && cd pdfcrack- make sudo cp pdfcrack /usr/local/bin/ </code></pre> Benchmark</h2> $ pdfcrack -b Benchmark: Average Speed (calls / second): MD5: 1728972.6 MD5_50 (fast): 97879.3 MD5_50 (slow): 69167.0 RC4 (40, static): 606555.3 RC4 (40, no check): 598050.0 RC4 (128, no check): 590141.7 Benchmark: Average Speed (passwords / second): PDF (40, user): 453510.2 PDF (40, owner): 220250.0 PDF (40, owner, fast): 499995.0 PDF (128, user): 22000.0 PDF (128, owner): 10408.7 PDF (128, owner, fast): 22220.0 </code></pre> Oversat:</p> RC4-40</strong> (PDF 1.3, meget gammel) — ~450k kodeord/sek. Brute-force af et fuldt 8-tegns alfanumerisk space: ~1 uge på én core.</li> RC4-128 / AES-128</strong> — ~22k kodeord/sek. Brute-force bliver urealistisk over længde 6 med et hvilket som helst charset.</li> AES-256 (R=5/6)</strong> — endnu langsommere; pdfcrack</code> understøtter det, men reelt kun til dictionary-angreb mod små ordlister.</li> </ul> Har du brug for mere fart end det, så vil du bruge hashcat</code> på en GPU. Tal i bunden.</p> Dictionary-angreb</h2> pdfcrack -f dokument.pdf -w /usr/share/wordlists/rockyou.txt </code></pre> -f</code></strong> — målfil.</li> -w <fil></code></strong> — ordliste, én kandidat pr. linje.</li> Valgfri -o</code></strong> — angrib kun owner-kodeord (ignorer user-kodeord). Default er at prøve user-kodeord først.</li> Valgfri -u</code></strong> — angrib kun user-kodeord.</li> </ul> Har du kontekst — kodeordet er sandsynligvis et fornavn, et årstal, en projektkode — saml en mindre målrettet liste. Generiske lister er en lang skud, når du er forbi top ti tusind indgange.</p> Brute-force-angreb</h2> pdfcrack -f dokument.pdf -c 'abcdefghijklmnopqrstuvwxyz0123456789' -n 4 -m 8 </code></pre> -c <charset></code></strong> — tegnsæt at prøve. Default inkluderer et bredt ASCII-område.</li> -n <min></code></strong> — minimumslængde.</li> -m <max></code></strong> — maksimumslængde.</li> </ul> Juster -c</code> aggressivt. Ved du, at kodeordet er alt-lowercase, så giv det ikke uppercase. Ved du, det har et ciffer til sidst, så brug et mask-angreb (hashcat-territorium, ikke pdfcrack).</p> Genoptag et langt kørsel</h2> pdfcrack -f dokument.pdf -w rockyou.txt -s /tmp/state.sav </code></pre> -s</code> skriver periodiske save-filer; hvis du stopper pdfcrack og genstarter, så giv -l /tmp/state.sav</code> for at genoptage.</p> Hvornår du skal skifte til hashcat</h2> Til enhver moderne PDF (R=4, 5 eller 6 — altså AES-128 eller AES-256) bliver pdfcrack</code>s single-core-fart flaskehalsen. pdf2john</code> + hashcat</code> giver dig to til tre størrelsesordener mere throughput på en GPU.</p> Trin 1: træk hashen ud</h3> $ /usr/share/john/pdf2john.pl dokument.pdf > hash.txt </code></pre> (På Debian/Ubuntu: apt install john</code> leverer pdf2john.pl</code>.)</p> Trin 2: identificér hash-mode</h3> $ head -1 hash.txt dokument.pdf:$pdf$56256-1028116... </code></pre> Map de første to tal:</p> $pdf$12...</code> → mode 10400</strong> (PDF 1.1–1.3, RC4-40, user)</li> $pdf$12...</code> med owner-salt → mode 10410 / 10420</strong></li> $pdf$23...</code> → mode 10500</strong> (PDF 1.4–1.6, RC4-128 / AES-128)</li> $pdf$55...</code> → mode 10600</strong> (PDF 1.7 r=5, AES-256)</li> $pdf$56...</code> → mode 10700</strong> (PDF 1.7 r=6 / PDF 2.0, AES-256 med PBKDF2)</li> </ul> Trin 3: kør hashcat</h3> hashcat -m 10700 hash.txt /sti/til/ordliste.txt </code></pre> På en enkelt moderne GPU (fx RTX 4090):</p> Mode 10400 (RC4-40):</strong> ~10 milliarder H/s — ethvert praktisk kodeord gendannes øjeblikkeligt.</li> Mode 10500 (RC4-128 / AES-128):</strong> ~100 millioner H/s.</li> Mode 10700 (AES-256, PBKDF2):</strong> ~50.000 H/s. Det er ved design — PBKDF2-iterationerne gør brute-force dyrt.</li> </ul> For mode 10700 betyder din angrebsstrategi mere end rå fart. Dictionary + regler + mask-angreb målrettet mod sandsynlige kodeord-mønstre er størrelsesordener mere produktive end udtømmende brute-force.</p> Almindelige faldgruber</h2> “Filen ser ud til at være krypteret, men jeg kan åbne den uden kodeord”</h3> Du ser på owner-only-restriktioner. Brug qpdf --decrypt input.pdf output.pdf</code> — ingen cracking nødvendigt.</p> pdfcrack kører, men finder aldrig noget</h3> Tre sandsynlige årsager:</p> Kodeordet er længere / mere komplekst, end dit charset × længde dækker.</strong> Øg -m</code> og/eller udvid -c</code>, eller skift til en dictionary.</li> Kodeordet indeholder ikke-ASCII-tegn.</strong> pdfcracks charset er ASCII som default; ikke-ASCII-user-kodeord i gamle PDF’er brugte varierende encodings (PDFDocEncoding, UTF-16). Prøv pdf2john</code> + hashcat, som håndterer encoding’en korrekt.</li> Det er AES-256 (R=6), og du er tålmodig.</strong> Se hastighedsnoterne ovenfor — kun realistisk med en dictionary.</li> </ol> “Only AES-256 is supported”-fejl eller lignende</h3> Din pdfcrack</code>-build er gammel. Ubuntu LTS leverer nogle gange en version, der ikke fuldt håndterer R=6. Byg fra kilden eller skift til pdf2john</code> + hashcat</code>.</p> PDF’en åbner, men print/kopi er blokeret</h3> Det er kun owner-kodeord-begrænset. qpdf --decrypt</code> uden at behøve et kodeord virker som regel:</p> qpdf --decrypt --password='' input.pdf output.pdf </code></pre> Defensiv pointe</h2> Til alt, du vil have til at forblive krypteret i 2026, brug AES-256 med en PDF 2.0 (R=6) kodeord</strong>. Det er profilen med PBKDF2-nøgle-afledning, der gør offline-angreb dyre på nuværende hardware.</p> Og som altid betyder kodeordets længde mere end noget andet. En 20-tegns tilfældig passphrase er brute-force-intraktabel mod enhver nuværende GPU. Et 6-tegns “smart substitutions”-kodeord er en kaffepause på en RTX 4090.</p> Ofte stillede spørgsmål</h2> Er pdfcrack stadig vedligeholdt?</h3> Opdateres langsomt. Kodebasen håndterer alle nuværende PDF-krypterings-profiler; det er bare ikke her, performance-arbejdet foregår længere (det er hashcat).</p> Bruger pdfcrack GPU?</h3> Nej. Kun CPU, single-threaded. Til GPU-arbejde, brug pdf2john</code> + hashcat</code>.</p> Kan pdfcrack gendanne dokumentet, hvis skaberen ryddede user-kodeordet, men beholdt owner-kodeordet?</h3> Ja — brug qpdf --decrypt</code> først; hvis det ikke fuldt dekrypterer, angriber pdfcrack -o</code> owner-kodeordet.</p> Lækker pdfcrack min PDF nogle steder?</h3> Nej. Den er lokal. Alt online-only (“crack min PDF på cloud-service-X.com”) indebærer at uploade filen, hvilket du ikke skal gøre for fortroligt materiale.</p> Hvad hvis jeg kun vagt husker kodeordet?</h3> Skriv ned, hvad du husker — sandsynlige ord, sandsynlige cifre, sandsynlig længde — og byg en målrettet ordliste eller et hashcat</code>-mask (-a 3 ?l?l?l?l?l?d?d?d?d</code>). Det slår enhver generisk liste.</p> Kan jeg gendanne tekst fra en AES-256-PDF uden kodeordet?</h3> Nej. AES-256 med PBKDF2 (R=6) er, så vidt offentlig kryptanalyse går, ikke brudt. Hvis kodeordet er stærkt og tabt, er indholdet tabt.</p> Opsummering</h2> Kun owner-kodeord?</strong> qpdf --decrypt</code>, ingen cracking nødvendigt.</li> User-kodeord-beskyttet, gammel (R=2/3)?</strong> pdfcrack</code> med en dictionary virker fint.</li> Moderne (R=4/5/6)?</strong> pdf2john</code> + hashcat</code> på en GPU, målrettet angreb.</li> Stærk 20-tegns tilfældig?</strong> Accepter tabet.</li> </ul> fcrackzip — gendan glemte zip-kodeord på Linux, macOS og Windows (2026) 2026-04-22T00:00:00+00:00 TL;DR —</strong> fcrackzip</code></strong> er et gratis, open-source kommandolinjeværktøj til at gendanne kodeordet på en krypteret .zip</code>-fil. Det understøtter brute-force</strong> (over et bruger-defineret charset og længde) og dictionary</strong>-angreb, virker på Linux/macOS/WSL, og er det rigtige første værktøj, når du skal gendanne et glemt kodeord på en zip, du lovligt ejer. Det er kun hurtigt mod klassisk ZipCrypto</strong>-kryptering; til den nyere AES-256</strong>-zip-profil virker fcrackzip</code> ikke — så skal du bruge zip2john</code> + hashcat</code> i stedet. Installeres med apt install fcrackzip</code> (Debian/Ubuntu), brew install fcrackzip</code> (macOS) eller bygges fra kilden.</p> Dette indlæg går gennem de praktiske tilfælde. Det antager, at du har autorisation til at gendanne kodeordet</strong> — dine egne filer, en kundes, en CTF. Brug det ikke på zips, du ikke ejer.</p> Installation</h2> # Debian / Ubuntu / Mint / Kali sudo apt install fcrackzip # macOS (Homebrew) brew install fcrackzip # Arch / Manjaro sudo pacman -S fcrackzip # Windows # Brug WSL2 + Ubuntu og `apt install fcrackzip`. # En native .exe findes, men er gammel — WSL er simplere. # Fra kilden git clone https://github.com/hyc/fcrackzip.git cd fcrackzip && ./configure && make sudo cp fcrackzip /usr/local/bin/ </code></pre> Tjek først, hvilken kryptering din zip bruger</h2> fcrackzip</code> håndterer kun klassisk ZipCrypto</strong> (den originale, svage PKZIP-kryptering). Til moderne AES-128 / AES-256</strong>-zips (introduceret af WinZip 9 i 2003, nu default i nogle værktøjer) vil fcrackzip</code> lydløst fejle i at finde kodeordet, uanset hvor længe du lader det køre.</p> Hurtigste tjek med zipinfo</code>:</p> $ zipinfo -v arkiv.zip | head -40 </code></pre> Led efter WinZip AES encryption, strength 3</code> (= AES-256). Ser du det, så spring til hashcat-sektionen.</p> Eller med 7z</code>:</p> $ 7z l -slt arkiv.zip | grep -i 'method\|encrypted' Method = ZipCrypto Store ← fcrackzip virker Method = AES-256 Deflate ← fcrackzip virker IKKE </code></pre> Grundlæggende brute-force</h2> fcrackzip -v -b -c 'a1' -p aaaa -u arkiv.zip </code></pre> -v</code></strong> — verbose.</li> -b</code></strong> — brute-force-mode.</li> -c 'a1'</code></strong> — charset. a</code> = små bogstaver a–z</code>, A</code> = store, 1</code> = cifre, !</code> = printbare symboler. Kombiner: 'aA1!'</code> = alt printbart ASCII (94 tegn).</li> -p aaaa</code></strong> — start-kodeord (definerer minimum-længde = 4 her).</li> -u</code></strong> — rapporterer kun, hvis den dekrypterede fil “unzipper” rent (filtrerer falske positive — ZipCrypto har en lille CRC, som mange tilfældige kodeord passerer).</li> </ul> Længde: -p aaaaa</code> starter ved 5 tegn. fcrackzip</code> har ikke et --max-length</code>-flag; det inkrementerer start-kodeordet gennem charsettet uendeligt, så at lade det køre til “færdigt” ved længde 8 på det fulde printbare ASCII-charset er ca. 94⁸ ≈ 6×10¹⁵ kandidater</strong> — ikke realistisk. Du afgrænser angrebet ved at vælge et rimeligt max charset + længde eller ved at bruge en dictionary.</p> Dictionary-angreb</h2> fcrackzip -v -D -u -p /usr/share/wordlists/rockyou.txt arkiv.zip </code></pre> -D</code></strong> — dictionary-mode.</li> -p <fil></code></strong> — ordliste-fil, én kandidat pr. linje.</li> -u</code></strong> — verificér via unzip, som før.</li> </ul> rockyou.txt</code> er den standard 14 M-indgange-ordliste, der leveres med Kali og er tilgængelig overalt. Har du kontekst om kodeordet (det er nogens navn + årstal, det er et projektkodenavn), så saml en mindre målrettet ordliste — hit-raterne er som regel meget højere end med en generisk liste.</p> Hastighed og hvad du kan forvente</h2> fcrackzip</code> er single-threaded og CPU-bundet. På en moderne laptop ser du groft:</p> 10–30 millioner ZipCrypto-forsøg pr. sekund pr. core</strong> for et dictionary-angreb mod en typisk zip.</li> Brute-force en anelse hurtigere pga. mindre streng-I/O.</li> </ul> Det gør den fin til:</p> Dictionary-angreb</strong> mod en hvilken som helst rimelig ordliste.</li> Kort brute-force</strong> (4–6 tegn alfanumerisk).</li> </ul> Det gør den uegnet til:</p> Længde 8+ med symboler</strong> — du når aldrig i mål.</li> AES-256-zips</strong> — forkert værktøj.</li> </ul> Hvornår du skal skifte til hashcat</h2> Hvis fcrackzip</code> er for langsom, eller zip’en er AES-krypteret, så gå over til hashcat</code>. Det er det general-purpose kodeord-cracking-værktøj, GPU-accelereret, og håndterer både ZipCrypto og AES-WinZip-hashes.</p> Trin 1: træk hashen ud med zip2john</code></h3> zip2john</code> er en del af John the Ripper. Ubuntu: apt install john</code>.</p> $ zip2john arkiv.zip > hash.txt $ cat hash.txt arkiv.zip:$zip2$030...$/zip2$::arkiv.zip:hemmelig.pdf:/sti/til/arkiv.zip </code></pre> Trin 2: fodr den til hashcat</h3> # ZipCrypto (mode 17200, 17210, 17220, 17225 afhængigt af komprimering) hashcat -m 17200 hash.txt /sti/til/ordliste.txt # AES-krypteret WinZip (mode 13600) hashcat -m 13600 hash.txt /sti/til/ordliste.txt </code></pre> På en enkelt moderne diskret GPU (fx RTX 4090) ser du:</p> ZipCrypto: ~5–10 milliarder H/s</strong></li> WinZip AES-256: ~10–50 millioner H/s</strong> (meget langsommere, fordi AES er dyrt, og der er PBKDF2-iterationer involveret)</li> </ul> hashcats rule-engine, mask-angreb (-a 3</code>) og combinator-mode (-a 1</code>) gør den massivt mere fleksibel end fcrackzip</code>. Til alt ikke-trivielt er den det rigtige værktøj.</p> Almindelige faldgruber</h2> “PASSWORD FOUND!!!!: pw == abc”, men unzip</code> beder stadig om et kodeord</h3> Du brugte ikke -u</code>. fcrackzips CRC-tjek har falske positive. Kør igen med -u</code> for at verificere kandidater mod et rigtigt dekomprimerings-forsøg.</p> Forskellige filer i samme zip har forskellige kodeord</h3> Klassisk PKZIP understøtter per-fil-kodeord. fcrackzip</code> angriber én fil ad gangen; giv -l <filnavn></code> (eller lad den vælge den første krypterede) hvis du skal være specifik.</p> fcrackzip finder kodeordet, men jeg kan stadig ikke unzippe</h3> Charset/locale-problem. Hvis kodeordet indeholder ikke-ASCII-tegn, har zip’ens skaber måske brugt en anden encoding end din terminal. Prøv unzip -P "$(echo -n 'passwd' | iconv -t cp437)" arkiv.zip</code>.</p> AES-krypteret, og dictionary finder det ikke</h3> hashcat + regler + en målrettet ordliste er løsningen. Se migrations-trinnene ovenfor.</p> Defensiv pointe</h2> Hvis du laver zip-filer, der skal forblive krypterede: brug AES-256</strong>, ikke ZipCrypto. De fleste moderne værktøjer (7z</code>, zip</code> fra InfoZIP med -e</code>, WinZip, Keka) giver dig AES, hvis du beder om det. Default på zip</code> er desværre stadig ZipCrypto på mange systemer. Tjek med 7z l -slt arkiv.zip</code> før du sender den afsted.</p> Og vælg et kodeord med længde, ikke smarthed. hashcat</code> er ligeglad med, hvor mærkeligt dit substitutions-mønster er; det handler kun om entropi. En fire-ords passphrase (correct-horse-battery-staple</code>-stil, ~44 bit) er fin mod offline ZipCrypto-angreb; et tilfældigt 12-tegns blandet kodeord (~78 bit) er fint mod GPU-AES-angreb. Alt kortere er genvindbart.</p> Ofte stillede spørgsmål</h2> Er fcrackzip lovligt?</h3> At gendanne kodeord på filer du ejer eller har autorisation til at tilgå, er lovligt i alle jurisdiktioner, jeg kender. At gøre det på en andens fil uden autorisation er uautoriseret adgang — samme lov som for enhver anden computer-indtrængen.</p> Er fcrackzip vedligeholdt?</h3> Kun lige. Kodebasen har været stabil i femten-plus år. Til moderne arbejde har kombinationen af zip2john</code> + hashcat</code> overtaget.</p> Kan fcrackzip bruge en GPU?</h3> Nej. fcrackzip</code> er kun CPU. Hvis GPU er det, du har, så gå direkte til hashcat.</p> Håndterer fcrackzip .7z, .rar, .gpg-filer?</h3> Nej — kun klassisk PKZIP .zip</code>. Til .7z</code>, brug 7z2john</code> + hashcat (mode 11600). Til .rar</code>, rar2john</code> + hashcat (mode 12500 / 13000). Til .gpg</code>, gpg2john</code> + hashcat (mode 17010+).</p> Hvordan genererer jeg en målrettet ordliste?</h3> hashcat</code>s maskprocessor (mp64</code>), crunch</code> og cewl</code> (crawler et site for kandidat-ord) er alle værd at kende. Til at gendanne et specifikt glemt kodeord er den højeste-yield-tilgang at skrive ned, hvad du husker om det — længde, sandsynlige ord, sandsynlige tal — og bygge et mask-angreb fra det.</p> Opsummering</h2> fcrackzip</code> + -D</code> + en ordliste er det rigtige første forsøg.</li> Virker det ikke, og det er ZipCrypto: fcrackzip</code> + -b</code> med et snævert charset og kort længde.</li> Virker det ikke, eller det er AES: zip2john</code> + hashcat</code> på en GPU.</li> Virker det ikke: dit kodeord var stærkt nok. Det er systemet, der virker som tiltænkt.</li> </ul> Wi-Fi-hacking gennem 25 år — 2002, 2007, 2012, 2017, 2022, 2027 2026-04-22T00:00:00+00:00 TL;DR —</strong> Wi-Fi-sikkerhed har været gennem fire generationer — WEP</strong>, WPA</strong>, WPA2</strong>, WPA3</strong> — hver introduceret, fordi forgængeren var brudt. Dette indlæg går gennem seks snapshots af state of the art: 2002</strong> (WEP, trivielt), 2007</strong> (WEP død, WPA udbredt, offline-angreb kommer frem), 2012</strong> (WPA2 dominerer, dictionary-angreb på GPU’er), 2017</strong> (KRACK bryder WPA2 under de rette betingelser, PMKID-lækken i 2018), 2022</strong> (WPA3 ruller ud, downgrade-angreb, cloud-skala-cracking), 2027</strong> (dagens landskab: WPA3 næsten universel, 6 GHz åbner ny overflade, angreb flytter op i stakken). For hvert år opsummerer jeg angrebet, værktøjet og hvad en forsvarer burde have gjort. Kun autoriseret testning — den defensive vejledning i bunden er pointen.</p> Overblik</h2> År</th> Dominerende standard</th> Hovedangreb</th> Indsats for typisk netværk</th> Hurtigste dictionary / nøgle-rate dengang</th></tr></thead> 2002</td> WEP (100%)</td> FMS statistisk IV</td> ~4M pakker / 2–10 t på aktivt AP</td> N/A — nøglen udledes af IV’er</td></tr> 2007</td> WEP 35%, WPA 25%, WPA2 20%, åben 20%</td> PTW + aircrack-ng</td> 40–85k pakker / <5 min (WEP)</td> ~50–100 PSK/s (CPU, cowpatty)</td></tr> 2012</td> WPA2 ~70%</td> Reaver (WPS) + GPU PSK dictionary</td> 11.000 WPS-PIN-forsøg / 2–10 t</td> ~75.000 PSK/s (GTX 580)</td></tr> 2017</td> WPA2 ~85%</td> KRACK; derefter PMKID (2018)</td> 1 pakke (PMKID) → offline dict</td> ~400.000 PSK/s (GTX 1080)</td></tr> 2022</td> WPA2 ~60%, WPA3 ~20%, mixed ~15%</td> Dragonblood downgrade</td> Tving WPA2-fallback, så GPU/cloud</td> ~1,2M PSK/s (RTX 3090), ~10M (8× A100)</td></tr> 2027</td> WPA3 ~40%, mixed ~35%, WPA2 ~20%</td> Klient-side + downgrade + chipset-FW</td> SAE intakt; legacy WPA2 på lånt tid</td> ~5–8M PSK/s (RTX 5090-klasse enkelt GPU)</td></tr> </tbody></table> Globale udbredelses-andele er omtrentlige, afledt af offentlige Wi-Fi-målinger (WiGLE-trends + leverandør-rapporter); regn med ± 10 procentpoint.</p> 2002 — WEP overalt, og trivielt brudt</h2> Standard:</strong> IEEE 802.11b med WEP</strong> (Wired Equivalent Privacy). 40-bit eller 104-bit RC4-nøgle, 24-bit IV, CRC-32-integritet.</p> Hvad er galt med den:</strong> IV’en er for lille, nøglerne er statiske, og RC4’s initial key schedule lækker bits af nøglen, når visse IV’er bruges. Det er FMS-angrebet</strong> (Fluhrer, Mantin, Shamir, 2001) og dets efterkommere.</p> Hvad en angriber gjorde i 2002:</strong> fangede trafik med en Prism-baseret USB-adapter, indsamlede et par millioner pakker (timer på et aktivt netværk) og udtrak nøglen med AirSnort</strong> eller WEPCrack</strong>. Angrebene var så pinlige, at Wi-Fi Alliance skubbede WPA som en midlertidig firmware-patchbar løsning i 2003.</p> Tal (2002):</strong></p> Global Wi-Fi-udbredelse:</strong> ~100% WEP (WPA blev først ratificeret marts 2003).</li> Nøglelængde:</strong> 40 bit (eksport-grade) eller 104 bit. Irrelevant — angrebet er på IV’en, ikke på nøglen.</li> IV-space:</strong> 24 bit → kun ~16,7 M mulige IV’er. Fødselsdags-kollision efter ~5.000 pakker.</li> FMS-angrebets pakke-antal:</strong> ~500 k–4 M “interessante” IV-frames (få timers aktiv trafik).</li> Typisk crack-tid i ur-tid:</strong> 2–10 t på et travlt SOHO-netværk.</li> Forbrugerhardware:</strong> én laptop + én Prism2/Prism2.5 USB-dongle (~$40 brugt dengang).</li> Værktøjer:</strong> AirSnort, WEPCrack, Kismet til capture.</li> CVE’er:</strong> WEP er ikke i sig selv en CVE, men Borisov/Goldberg/Wagner (2001) og FMS-paperet (2001) er de kanoniske referencer.</li> </ul> Hvad en forsvarer burde have gjort:</strong> erkendt, at WEP ikke er en sikkerhedsfunktion, og behandle det trådløse LAN som ubetroet. Brug en VPN eller IPSec på lag 3.</p> 2007 — WEP død, WPA overgangsvis, WPA2 på vej</h2> Standard:</strong> WPA (2003), en nød-løsning med per-pakke-nøgler (TKIP). WPA2 (2004) med AES-CCMP begynder at dukke op i hjemme-routere.</p> Hvad der er nyt for angribere:</strong> PTW-angrebet</strong> på WEP (2007) reducerer pakke-antallet fra ~1 million til ~40.000 — WEP kan nu crackes på minutter. aircrack-ng</strong> bliver den kanoniske toolkit. Mod WPA-Personal bliver offline-dictionary-angreb på 4-way-handshake praktiske på CPU’er: fang en handshake, fodr PSK-afledningen gennem cowpatty</code> eller aircrack-ng</code>, prøv dictionary-indgange én ad gangen.</p> Hvad angribere endnu ikke havde:</strong> meningsfuld GPU-acceleration af WPA-PSK. Dictionary-angreb var langsomme.</p> Tal (2007):</strong></p> Global udbredelse (WiGLE-målinger):</strong> WEP ~35%, WPA ~25%, WPA2 ~20%, åben ~20%.</li> PTW-angrebets pakke-antal:</strong> ~40.000–85.000 fangede frames for at gendanne en WEP-nøgle (ned fra millioner).</li> Crack-tid med aircrack-ng + pakke-injektion:</strong> <5 minutter, ofte under 60 sekunder.</li> WPA-PSK dictionary-rate (CPU, cowpatty/aircrack-ng):</strong> ~50–100 kandidater/sek pr. core.</li> Rockyou-ordliste</strong> (lækket dec. 2009): 14,3 M indgange — blev de-facto engelsk PSK-ordliste.</li> WPA2 obligatorisk for Wi-Fi CERTIFIED:</strong> marts 2006.</li> Aircrack-ng 1.0:</strong> udgivet 2006, konsoliderede økosystemet.</li> </ul> Hvad en forsvarer burde have gjort:</strong> migrere til WPA2-AES-CCMP, vælg en PSK længere end nogen dictionary. Drop WEP-netværk helt.</p> 2012 — WPA2 dominerer, GPU-cracking moden</h2> Standard:</strong> WPA2 er default på stort set al consumer-gear. WPA2-Enterprise (802.1X / EAP) i corporate-netværk.</p> Hvad der er nyt for angribere:</strong> hashcat</strong> og oclHashcat</strong>, pyrit</strong> og John the Ripper</strong> gør WPA-PSK-dictionary-angrebet til et GPU-problem</strong>. En handshake-capture + en enkelt moderne GPU klarer titusindvis af kandidat-PSK’er pr. sekund; en lille lejet GPU-farm håndterer hundredtusinder. airodump-ng</strong> + Reaver</strong> (2011) udnytter en implementerings-fejl i WPS-PIN</strong> til at gendanne WPA-PSK’en helt uden en dictionary — en dødsdom for hjemme-routere med WPS-on-by-default.</p> Tal (2012):</strong></p> Global udbredelse:</strong> WPA2 ~70%, WEP ~10%, åben ~15%, WPA ~5%.</li> WPS-PIN-space på papir:</strong> 10⁸ = 100 millioner. Effektiv</strong> angrebs-space efter Viehböck-splittet: 10⁴ + 10³ = ~11.000 forsøg.</li> Reaver ur-tid til at gendanne WPS-PIN → PSK:</strong> 2–10 timer mod en upatched AP.</li> hashcat WPA-PSK throughput på GTX 580 (reference-GPU 2012):</strong> ~75.000 kandidater/sek.</li> hashcat WPA-PSK på en lille 4-GPU-rig fra æraen:</strong> ~300.000 kandidater/sek, dvs. rockyou.txt</code> (14,3 M) på ~50 sekunder.</li> Virkelig PSK-gendannelsesrate med rockyou + almindelige regler:</strong> ~20–25% på fangede handshakes i akademiske studier.</li> WPA2-PEAP/MSCHAPv2-hashrate (et Wi-Fi-tilstødende Enterprise-problem):</strong> titusinder af millioner/sek på en enkelt GPU, fuldt 2²⁸-keyspace inden for et døgn.</li> </ul> Hvad forsvarere burde have gjort:</strong></p> Slå WPS fra.</strong> De fleste routere havde den tændt som default.</li> Brug lange tilfældige PSK’er</strong>, ikke dictionary-ord.</li> Til enterprise: 802.1X + EAP-TLS med klient-certifikater</strong>, ikke PEAP-MSCHAPv2 (som i sig selv er et GPU-problem).</li> </ul> 2017 — KRACK</h2> Standard:</strong> WPA2 stadig overalt.</p> Hvad der er nyt for angribere:</strong> KRACK</strong> (Vanhoef, Piessens, 2017) — Key Reinstallation Attack. Det cracker ikke PSK’en. Det udnytter en subtil fejl i 4-way-handshaken, hvor, under visse betingelser (specifikt på Android 6+ og wpa_supplicant 2.4–2.6), genafspilning af handshake-meddelelse 3 får klienten til at geninstallere en all-zero session-nøgle</strong>. Derfra kan angriberen dekryptere udvalgt trafik og, afhængigt af cipher suite, injicere pakker.</p> Hvad gjorde KRACK anderledes end tidligere angreb:</strong> det ramte protokollen, ikke nøglen</strong>. En stærk PSK hjalp ikke. Hver WPA2-implementation havde brug for en patch. De fleste leverandører leverede en inden for uger; nogle tog år.</p> Også i denne æra:</strong></p> PMKID hashcat-angrebet</strong> (2018, Steube). Mange AP’er lækker PMKID’en i en enkelt besked; én pakke er nok til at starte et offline PSK-angreb. Sænkede capture-barren yderligere — ingen klient-association nødvendig.</li> Evil twin / captive portal-phishing.</strong> Efterhånden som enheds-UI’er blev smukkere, blev falske captive portals alarmerende effektive mod mennesker.</li> </ul> Tal (2017–2018):</strong></p> Global udbredelse:</strong> WPA2 ~85%, WEP <3%, åben ~10%, WPA3 endnu ikke leveret.</li> KRACK CVE’er:</strong> 10 i den koordinerede offentliggørelse (CVE-2017-13077 til CVE-2017-13088).</li> KRACK-berørte enheder:</strong> alle WPA2-klienter og AP’er — 10+ milliarder</strong> endpoints. Reel patching tog år for long-tail-IoT.</li> Patch-latency hos leverandører:</strong> Microsoft / de fleste Linux-distroer inden for 1 uge fra disclosure; Android 2+ måneder afhængigt af OEM; mange embedded-enheder blev aldrig patchet.</li> PMKID-angrebets pakke-antal:</strong> 1 enkelt frame</strong> mod 4-way-handshakens 4 frames — ingen klient-association eller deauth nødvendig.</li> hashcat på GTX 1080 (reference-GPU 2017):</strong> ~400.000 WPA-PSK-kandidater/sek — ~5× hurtigere end 2012.</li> En lejet 8× 1080 Ti-instans (~$4/t i 2017):</strong> ~3M kandidater/sek — rockyou.txt</code> på <5 sekunder.</li> Koordineret disclosure-forløbstid:</strong> 4 måneder fra leverandør-notificering til offentlig release.</li> </ul> Hvad en forsvarer burde have gjort:</strong> patch Android / wpa_supplicant straks, håndhæv HTTPS overalt, så dekrypteret Wi-Fi-trafik er mindre nyttig, begynd at planlægge WPA3-migration.</p> 2022 — WPA3 ruller ud, downgrade-angreb</h2> Standard:</strong> WPA3 (2018) påkrævet til Wi-Fi CERTIFIED-enheder siden 2020. Nøgle-opgraderinger:</p> SAE</strong> (Simultaneous Authentication of Equals) erstatter 4-way-handshake-PSK’en — offline-dictionary-angreb bliver ufremkommelige.</li> 192-bit mode</strong> til Enterprise.</li> Forward secrecy</strong>.</li> PMF</strong> (Protected Management Frames) obligatorisk — neutraliserer deauth-baseret denial-of-service.</li> </ul> Hvad der er nyt for angribere:</strong> WPA3 er ikke brudt, men dens udrulning er for det meste ikke WPA3-kun</strong>. WPA2/3-transition-mode</strong> — default på de fleste AP’er — betyder, at en angriber kan tvinge en downgrade og angribe som WPA2. Det er Dragonblood</strong> (Vanhoef, Ronen, 2019 + opfølgninger): en familie af side-channel- og downgrade-angreb mod SAE. I 2022 lukkede patchede SAE-implementationer for det meste timing-side-channels; downgrade-angrebet virker stadig på mixed-mode-netværk.</p> Også i denne æra:</strong></p> Cloud-skala-cracking</strong>: at leje 8× H100 eller lignende på timebasis gør PMK-dictionary-angreb praktiske på en skala, ingen amatør havde i 2012.</li> Chipset-firmware-sårbarheder</strong> (FragAttacks, 2021): fejl i selve Wi-Fi-stakken, under WPA-laget, lader angribere injicere frames uden at skulle bryde en handshake overhovedet.</li> </ul> Tal (2022):</strong></p> Global udbredelse:</strong> WPA2-only ~60%, WPA3 ~20%, WPA2/3-transition-mode ~15%, WEP <1%.</li> WPA3-understøttelse på nye routere:</strong> ~60% af forbruger-AP’er leveret i 2022 understøttede WPA3 (vs. ~10% i 2020).</li> Dragonblood CVE’er:</strong> 5 (CVE-2019-9494 til CVE-2019-9499).</li> FragAttacks CVE’er:</strong> 12 i 2021-bundlet.</li> hashcat WPA-PSK på RTX 3090:</strong> ~1,2M kandidater/sek.</li> 8× A100-cloud-instans:</strong> ~10M kandidater/sek samlet. rockyou.txt</code> på ~1,5 sekund; et 10 mia.-kandidats mask-angreb på ~17 minutter.</li> Pris pr. milliard PSK-forsøg på spot-cloud-GPU’er:</strong> ~$3–5.</li> 12-tegns fuldt tilfældig PSK-entropi:</strong> 2⁷² ≈ 4,7 × 10²¹. Ved 10M H/s er udtømmende angreb = ~15.000 år</strong>. Sikker.</li> 8-tegns små-bogstav+ciffer PSK-entropi:</strong> 2⁴¹ ≈ 2,2 × 10¹². Ved 10M H/s: ~2,5 døgn</strong>. Ikke sikker.</li> </ul> Hvad en forsvarer burde have gjort:</strong> WPA3-Personal kun (ingen WPA2-transition) på netværk, hvor du kan håndhæve det; PMF påkrævet; lang tilfældig PSK selv med SAE; hold AP-firmware opdateret.</p> 2027 — dagens landskab</h2> Standard:</strong> Wi-Fi 6E (6 GHz) og tidlige Wi-Fi 7-udrulninger. WPA3 næsten universel på nyt gear; legacy WPA2 stadig almindelig i små virksomheder og længe-levende hjemme-netværk.</p> State of the art i angreb:</strong></p> SAE holder.</strong> Intet offentligt, praktisk angreb mod et velkonfigureret WPA3-Personal-netværk i 2027. Dictionary-angreb mod PSK’en er ikke fremkommelige — det er SAE’s pointe.</li> Downgrade-angreb</strong> er den primære ting. Ethvert netværk, der stadig annoncerer WPA2/3-transition, kan angribes som WPA2. Modstandere kigger efter mixed-mode-SSID’er først.</li> 6 GHz åbner ny overflade.</strong> 6 GHz-båndet kræver WPA3 til nye standarder; men legacy-klient-bridging, IoT-enheder uden 6 GHz-understøttelse og fejlkonfigureret co-broadcast-SSID’er skaber inkonsistenser, angribere udnytter.</li> Klient-side-angreb.</strong> Når link-laget er sikkert, flytter angribere op. Rogue-captive-portals der snyder telefoner til at stole på et dårligt certifikat, QR-kode-tilslutning med falske SSID’er, deauth-under-roaming-angreb (sværere nu med PMF, men ikke elimineret).</li> Supply chain.</strong> Firmware-indlejrede bagdøre og vendor-bugs i Wi-Fi-chipsets (FragAttacks-arven) er stadig en varig kilde til exploits.</li> Cloud-cracking er blevet commodity.</strong> Et weekend-langt SAE-offline-angreb (i de tilfælde, hvor offline-angreb er muligt, altså målet kørte en upatched SAE) koster groft prisen på en pæn middag. Det betyder for det meste intet, fordi SAE ikke er reducerbart til offline-dictionary-angreb — men det skubber økonomien på legacy-WPA2-netværk, folk ikke har migreret.</li> </ul> Værktøjer stadig i rotation i 2027:</strong> aircrack-ng (ældre, stadig kanonisk til captures og WPA2), hashcat (cracking), bettercap (Wi-Fi MITM / rogue AP), airgeddon (workflow-lim) og en bølge af ESP32-baserede lomme-værktøjer til opportunistisk deauth og handshake-capture.</p> Tal (2027):</strong></p> Global udbredelse:</strong> WPA3 ~40%, WPA2/3-transition ~35%, WPA2-only ~20%, WEP ~0,5% (lang hale af gammelt gear).</li> Enterprise-andel der kører WPA3-Enterprise 192-bit mode:</strong> stadig <10%. De fleste corporate-netværk er stadig WPA2-Enterprise med PEAP.</li> Ny-enhed WPA3-certificering:</strong> obligatorisk for Wi-Fi 6 siden 2020, Wi-Fi 6E (6 GHz) siden 2022, Wi-Fi 7 fra launch.</li> hashcat WPA-PSK på RTX 5090-klasse enkelt-GPU (2025+):</strong> ~5–8M kandidater/sek.</li> 8× H100-cloud-instans:</strong> ~50M kandidater/sek samlet. rockyou.txt</code> på ~0,3 sekund.</li> SAE (WPA3-Personal) offline-angreb:</strong> ufremkommeligt ved enhver hash-rate — handshaken udleverer ikke en crackbar hash til en aflytter.</li> Pris for at brute-force en svag 8-tegns WPA2-PSK i 2027:</strong> <$10 på spot-cloud-GPU’er.</li> Pris for at brute-force en 12-tegns tilfældig WPA2-PSK:</strong> stadig ~$10⁹ (samme regnestykke som 2022, GPU’er 5× hurtigere → stadig årtusinder).</li> ESP32-S3 “Wi-Fi Nugget” / Flipper Zero-klasse lomme-værktøjer</strong> i cirkulation i 2027: hundredtusinder af enheder. Opportunistisk handshake-capture er trivielt; PSK-cracking er stadig offline på en kraftig host.</li> Deauth-DoS-effektivitet:</strong> nær-nul på PMF-required-netværk; virker stadig mod de ~30% af udrullede AP’er, hvor PMF er “capable”, men ikke “required”.</li> </ul> Bundlinje: mod WPA3-Personal med SAE, PMF påkrævet og en tilfældig PSK</strong> kommer intet af 2027-værktøjssættet ind via link-laget. Mod en typisk 2019-vintage hjemme-router, der stadig kører WPA2 med en svag PSK og WPS valgfrit eksponeret</strong>, er en weekend på en mellem-klasse-GPU rigeligt.</p> Defensiv vejledning for 2027</h2> Det er den del, der betyder mere end al historien.</p> WPA3-Personal SAE-only eller WPA3-Enterprise med EAP-TLS.</strong> Ingen transition-mode på noget netværk, du kan kontrollere. Tjek eksplicit — mange AP’er default til transition.</li> PMF påkrævet, ikke valgfrit.</strong> Protected Management Frames forhindrer deauth-drevne handshake-captures og basal denial-of-service.</li> PSK-længde: tilfældig, ≥ 20 tegn.</strong> SAE gør korte PSK’er sikrere end de plejede at være, men ingen grund til at spille.</li> Slå WPS permanent fra.</strong> Selvom WPS-PIN-angrebet er oldgammelt, leverer mange routere stadig med det aktiveret for “bekvemmelighed”.</li> Gæste-SSID isoleret.</strong> Klient-til-klient-isolation slået til og routet til et separat VLAN uden intern LAN-adgang.</li> IoT-SSID, separat og indelukket.</strong> Billige Wi-Fi-termostater og legetøj er det svageste led på de fleste hjemme-netværk. De får deres eget SSID, deres eget VLAN og ingen rute til noget vigtigt.</li> Firmware-opdateringer på AP’er.</strong> De fleste interessante 2020’er-Wi-Fi-sårbarheder var på chipset-niveau; rettelsen er altid en firmware-opdatering. Køb AP’er fra en leverandør, der leverer dem.</li> Antag at link-laget vil fejle og forsvar dig over det.</strong> HTTPS overalt, klient-certs på alt, der betyder noget, VPN eller Tailscale til fjernadgang. Når (ikke hvis) nogen bryder din Wi-Fi, skal lag 4+ stadig holde.</li> </ul> Hvad der forblev det samme gennem 25 år</h2> Tre mønstre gentager sig ved hver generation:</p> Kryptografien er næsten altid stærkere end udrulningerne.</strong> WEP var en design-fejl; WPA2 og WPA3 er blevet brudt af implementerings-fejl, downgrade-stier og side-channels — ikke af rene krypto-svagheder.</li> Defaults betyder mere end kapabiliteter.</strong> WPS tændt som default, WPA2/3-transition-mode tændt som default, gæste-netværk uden isolation som default — det er det, angribere faktisk finder, i skala.</li> Angriberen flytter altid op i stakken.</strong> Når link-lags-sikkerheden forbedres, skifter angreb til captive portals, falske certs, klient-fejlkonfigurationer og phishing. Ingen mængde WPA3 retter brugeren, der klikker “Stol på” på evil-twin’ens falske certifikat.</li> </ol> Coda</h2> Hvis denne posts forfader på dette site, fra 2010, var “Hvordan man hacker et trådløst netværk” og fokuserede på WEP med aircrack-ng</code>, er 2027-versionen tættere på “Hvordan man tænker om Wi-Fi-sikkerhed” og fokuserer på konfiguration, patching og realistisk trussels-modellering. Kryptografien har gjort sit arbejde. Lagene omkring den er den interessante front nu.</p> Test dine egne netværk — eller netværk, du er autoriseret til at teste — test ikke nogen andens. Samme lov, der gjaldt i 2002, gælder i 2027.</p> nemboks.dk — få din digitale post (mit.dk, e-Boks) sendt direkte til din e-mail 2026-04-22T00:00:00+00:00 TL;DR —</strong> nemboks.dk</a> videresender digital post</strong> (fra mit.dk</a> og e-Boks</a>) direkte til din e-mail. Problemet, det løser: digital post er i teorien “push”, men i praksis “pull” — du skal stadig logge ind med MitID, åbne en app og klikke rundt for at læse et brev fra SKAT eller kommunen. Nemboks laver det til en e-mail, der lander i den indbakke, du i forvejen bor i — med PDF’en vedhæftet. Bygget til danske SMV’er, hvor samme virksomhed</code> modtager post for flere selskaber eller medarbejdere, og hvor revisorer, bogholdere og ejendomsadministratorer vil have digital post samme sted som al anden e-mail. Gratis beta; efter beta koster det 39 kr/md på årlig betaling, 49 kr/md månedlig.</p> Problemet med dansk digital post</h2> Siden 2014 er kommunikation fra det offentlige digital som udgangspunkt. Det betyder, at hvis din kommune, SKAT, Udbetaling Danmark eller FerieKonto skal fat i dig, lægger de brevet i enten mit.dk</a></strong> (den offentlige portal) eller e-Boks</a></strong> (historisk set den mest brugte private portal, nu koblet til Digital Post).</p> I princippet er det fint: samlet, sporbart, ingen papir. I praksis er der en masse friktion:</p> Du skal logge ind med MitID hver gang.</strong> Hvert skattebrev, hver p-afgift, hver feriepenge-besked ligger bag en MFA-flow.</li> Apps notificerer dig, men notifikationerne er tynde.</strong> “Du har ny post” — ikke emnelinje, ikke afsender, ikke nok til at prioritere.</li> Der er ingen indbygget videresendelse.</strong> Du kan ikke sige “send alt fra SKAT til min bogholder på bogholder@firma.dk</code>”.</li> Virksomheder får det værste af begge verdener.</strong> En CVR-registreret virksomhed har sin egen mit.dk / e-Boks-indbakke. Hvis indehaveren ikke tjekker den, er der ingen, der gør.</li> </ul> E-mail er omvendt standard-indbakken for små virksomheder: delte postkasser, videresendelsesregler, arkivering, filtre, søgning. Nemboks bygger broen imellem.</p> Hvad Nemboks gør</h2> Når Nemboks er sat op, logger den på din mit.dk / e-Boks på dine vegne, tjekker for ny post og sender hvert nyt brev videre — som en rigtig e-mail med PDF’en vedhæftet</strong> — til den eller de adresser, du har konfigureret.</p> En e-mail pr. brev.</strong> Emne = afsender + emne. Brødtekst = tekst-preview. Vedhæftning = PDF’en.</li> Flere selskaber pr. konto.</strong> Hvis du er revisor for flere CVR’er, bor de alle under samme Nemboks-dashboard.</li> Flere destinationer pr. selskab.</strong> Send f.eks. alt fra SKAT til bogholderen, resten til ejeren.</li> Originalen bliver liggende i mit.dk / e-Boks.</strong> Intet slettes — Nemboks læser kun.</li> Logger hver videresendelse.</strong> For revision og ro i maven.</li> </ul> Det praktiske resultat: revisoren eller bogholderen, der allerede bor i Outlook eller Gmail, holder op med at skifte kontekst til en portal en gang om ugen.</p> Hvem det er til</h2> Nemboks er bygget til danske SMV’er, især:</p> Revisorer og bogholdere.</strong> Kunden giver adgang én gang; derefter bliver hvert SKAT-brev for hver kunde til en e-mail i den delte indbakke.</li> Ejendomsadministratorer.</strong> En enkelt administrator kan sidde med post for dusinvis af ejendoms-A/S og -ApS.</li> Smv-indehavere.</strong> Enkeltmandsvirksomheden eller to-mands-ApS, hvor ejeren hellere vil have brevet fra kommunen samme sted som sin kunde-mail.</li> </ul> Stakken</h2> For de nysgerrige:</p> Rails 8</strong> på Ruby 3.4 med Hotwire (Turbo + Stimulus) og Tailwind til dashboardet.</li> PostgreSQL</strong> til persistens.</li> Auth0</a></strong> til autentificering. Brugerne logger på med Google, Microsoft eller e-mail+kodeord — ingen separat Nemboks-kodeord at glemme.</li> Stripe</a></strong> til abonnementsstyring, inkl. deres hostede kundeportal til selv-betjent kortopdatering og opsigelse.</li> Postmark</a></strong> til transaktionel e-mail — de er kategoriens standard for “e-mail der skal lande i indbakken”, hvilket er hele pointen med en videresendelses-tjeneste.</li> Docker + Kamal</strong> til deployment. Zero-downtime rollouts på en lille flåde; ingen Kubernetes at drifte.</li> Cloudflare Pages</strong> til det statiske marketing-site på nemboks.dk</a>.</li> </ul> Opdelingen — Rails-app på Kamal, marketing-site på Pages — er bevidst. Marketing-sitet skal være billigt, hurtigt og tungt cached; Rails-appen skal have database og baggrundsjobs. At køre dem som to separate deployments holder hver af dem simpel.</p> Pris</h2> Gratis beta</strong>, mens tjenesten stabiliseres.</li> Efter beta: 39 kr/md</strong> på årlig betaling, 49 kr/md</strong> månedlig — excl. moms. Flad pris pr. selskab; ingen pris pr. brev.</li> 60 dages gratis prøveperiode</strong> til nye kunder efter beta.</li> </ul> Ofte stillede spørgsmål</h2> Må Nemboks læse min mit.dk / e-Boks?</h3> Ja — som indbakke-ejer giver du Nemboks lov til at læse på dine vegne. Nemboks læser kun; intet slettes, besvares eller markeres som læst uden at du har konfigureret det.</p> Er det GDPR-compliant?</h3> Nemboks behandler persondata på dine vegne. Som kunde er du dataansvarlig; Nemboks er databehandler, og der er en standard databehandleraftale (DPA) at underskrive. Alle data opbevares i EU.</p> Hvad sker der med det originale brev i mit.dk / e-Boks?</h3> Det bliver liggende. Nemboks er read-only.</p> Kan jeg videresende til flere e-mailadresser?</h3> Ja. Hvert selskab kan have flere modtagere, og du kan sende forskellige afsendere til forskellige adresser (f.eks. alt fra SKAT til bogholderen).</p> Virker Nemboks for privatpersoner?</h3> Det nuværende fokus er danske virksomheder (CVR). En privat-plan kommer måske senere.</p> Hvad hvis Nemboks går ned?</h3> Din post lander stadig i mit.dk / e-Boks som normalt; Nemboks videresender bare ikke, før tjenesten er tilbage. Intet går tabt.</p> Hvordan opsiger jeg?</h3> Via Stripes kundeportal inde fra dashboardet. Ingen e-mail, intet telefonopkald.</p> Hvorfor bygge det</h2> Digital post virker. Det er sikkert, sporbart, og jeg vil hellere have et SKAT-brev i mit.dk end en brun kuvert. Men brugerfladen er designet til en borger, der læser en håndfuld breve om året — ikke til en virksomhed, der får dusinvis om ugen på tværs af flere CVR’er. E-mail løser “dusinvis om ugen på tværs af flere postkasser” udmærket — filtre, regler, delte indbakker, søgning — så den mindst interessante, men mest nyttige bro er at få brevene ud af portalen og ind i e-mailen med PDF’en vedhæftet, uden at nogen skal logge ind hver gang.</p> Det er Nemboks.</p> Sådan afspiller du Spotify på en Logitech Squeezebox i 2026 2026-04-22T00:00:00+00:00 TL;DR —</strong> Det officielle Spotify-plugin, Logitech leverede med Squeezebox, holdt op med at virke, da Spotify lukkede libspotify</code>-API’en i 2022. I 2026 er der to fungerende veje til at få Spotify på en Squeezebox Classic, Touch, Boom, Radio eller Transporter</strong>: (1) Logitech Media Server + Spotty-plugin’et</a></strong> (nu omdøbt Spotty</code> / nogle gange Spotty-XL</code>), der bruger Spotifys Web API plus librespot</code> under motorhjelmen, eller (2) kør spotifyd</a></strong> på samme host som LMS og peg LMS på den som generisk lydkilde. Vej 1 er den, du vil bruge, medmindre du har en grund til andet. Dette indlæg gennemgår den.</p> Hvad skete der med det officielle plugin</h2> Squeezebox-hardware gik end-of-life hos Logitech i 2012, men softwaren — Logitech Media Server (LMS)</strong>, det der faktisk streamer musik til enhederne — er blevet community-vedligeholdt siden. I årevis leverede den et officielt “Spotify”-plugin, der brugte Spotifys nu udfasede libspotify</code> C-bibliotek. Da Spotify lukkede libspotify</code> i 2022, holdt det plugin op med at virke, og Spotify har ikke leveret en erstatning til tredjeparts-indbyggede enheder.</p> Community’et udfyldte hullet:</p> librespot</code></strong> — en open-source Rust-reimplementering af Spotify Connect-klientprotokollen. Grundlaget for de fleste moderne tredjeparts-Spotify-integrationer.</li> Spotty-plugin til LMS</strong> — pakker librespot</code> og Spotifys Web API ind i et LMS-plugin. Præsenterer Spotify-browsing, søgning, playlister og afspilning inde i Squeezebox-UI’et (både enheds-skærmen og LMS-web-UI’et).</li> spotifyd</strong> — en selvstændig librespot</code>-baseret dæmon, der fremstår som et Spotify Connect-mål. Din telefon ser den som en højttaler, du caster til den, og dens lydudgang går et sted hen, hvor LMS kan samle det op.</li> </ul> Vej 1 (anbefalet): Spotty-plugin på LMS</h2> Dette er den reneste oplevelse og den, der føles native på Squeezeboxen. Du søger og browser fra Squeezebox-fjernbetjeningen eller Touch-skærmen, og det Virker Bare.</p> 1. Få LMS op at køre</h3> Hvis du ikke allerede kører LMS, så installér det på en altid-tændt maskine — en Raspberry Pi, et NAS med Docker eller en lille Linux-boks er ideelt.</p> # Debian/Ubuntu — hent den nyeste .deb fra community-repoet wget https://downloads.slimdevices.com/LogitechMediaServer_v8.x/logitechmediaserver_<latest>_amd64.deb sudo apt install ./logitechmediaserver_<latest>_amd64.deb sudo systemctl enable --now logitechmediaserver </code></pre> Eller via Docker — lmscommunity/logitechmediaserver</code> er et vedligeholdt image:</p> docker run -d --name lms \ --network host \ -v lms-config:/config \ -v /sti/til/musik:/music:ro \ lmscommunity/logitechmediaserver:latest </code></pre> Åbn http://<host>:9000/</code>, og du skulle se LMS-web-UI’et. Dine Squeezebox-enheder på samme LAN skal dukke op under Players</strong> automatisk.</p> 2. Installér Spotty</h3> I LMS-web-UI’et: Settings → Plugins → Install new plugins</strong> og kryds Spotty</strong> af (forfatter: Michael Herger). LMS henter, installerer og genstarter. Efter genstart har du et Spotty</strong>-punkt i Settings → Advanced → Spotty</strong>.</p> 3. Autoriser Spotty med din Spotify-konto</h3> I Settings → Advanced → Spotty</strong> klik Add account</strong>.</li> Spotty starter et OAuth-flow via Spotifys Web API — du logger ind én gang i en browser, godkender adgangen, og tokenet gemmes på LMS-serveren.</li> Du skal bruge Spotify Premium</strong> til afspilning. (Det er en Spotify-side-grænse: librespot</code> kan autentificere med Free, men fuld-kvalitets-afspilning er kun til Premium.)</li> </ul> 4. Afspil noget</h3> På selve Squeezebox-enheden: Home → My Music → Spotty</strong> (eller Home → Music Library → Spotty</strong>, afhængigt af din LMS-version) — browsing af playlister, søgning, start et nummer. På Squeezebox Touch virker artwork på skærmen. På Classic virker tekst-UI’et. På Radio og Boom styrer du det fra web-UI’et eller apps som Squeeze Commander</a> / Squeezer</a>.</p> Spotty tilføjer også Squeezebox-enheder som Spotify Connect-mål</strong> — det betyder, at du kan caste fra din telefon-Spotify-app til “Stue-Squeezeboxen” native, på samme måde som du ville caste til en Sonos eller en Google Home.</p> Vej 2: spotifyd som Connect-bro</h2> Brug denne, hvis Spotty ikke vil installere (gammel LMS-version, gammel Perl, mærkeligt OS) eller du specifikt vil have Spotify Connect-adfærd uden Spotty.</p> # Debian/Ubuntu sudo apt install spotifyd # eller fra kilden: cargo install spotifyd </code></pre> Konfigurér /etc/spotifyd.conf</code> med dine Spotify-credentials, en backend (alsa</code>, pulseaudio</code> eller pipe</code>) og et enhedsnavn. Start dæmonen:</p> sudo systemctl enable --now spotifyd </code></pre> Fra din telefon, cast til den spotifyd</code>-navngivne enhed. Lyden kommer ud af hosten.</p> For at få den lyd ind i en Squeezebox, pipe spotifyd</code> til en FIFO og afspil FIFO’en i LMS:</p> # spotifyd.conf backend = "pipe" device = "/var/run/spotifyd.pipe" </code></pre> Tilføj derefter FIFO’en som en File system music folder</strong> i LMS og afspil den som en live-stream.</p> Det er klodset og har ~1 s forsinkelse i forhold til Spottys tætte integration. Brug det kun, hvis vej 1 ikke virker for dig.</p> Virker på hvilke Squeezeboxe?</h2> Spotty virker på alle Squeezebox-enheder, der taler med LMS:</p> Squeezebox Classic / Squeezebox v3</strong> (tekstdisplay) — tekst-UI-browsing og afspilning.</li> Squeezebox Touch</strong> — farvetouchskærm, artwork, hele UI’et.</li> Squeezebox Boom</strong> — tekst-UI, samme som Classic.</li> Squeezebox Radio</strong> — tekst-UI, indbygget højttaler.</li> Squeezebox Duet / Controller</strong> — controllerens UI virker; afspilning går til Receiveren.</li> Transporter</strong> — fuld understøttelse.</li> piCorePlayer / SqueezeLite på Pi</strong> — ja, det er software-Squeezeboxe, og Spotty streamer fint til dem.</li> </ul> Så længe enheden kan forbinde til LMS, kan Spotty fodre den.</p> Ofte stillede spørgsmål</h2> Skal jeg have Spotify Premium?</h3> Ja, til afspilning. librespot</code> (og dermed Spotty) kræver en Premium-konto for at afkode lyd. Spotify Free-konti kan autentificere, men kan ikke afspille.</p> Virker “Squeezeboxen som Spotify Connect-højttaler”?</h3> Ja, med Spotty installeret. Hver Squeezebox-player dukker op i Spotify-appens enhedsvælger som et Connect-mål.</p> Virker hi-res / lossless?</h3> Spotify tilbyder ikke selv lossless på standardplaner (Hi-Fi har været “kommer snart” i årevis). Spotty afspiller, hvad Spotify serverer — Ogg Vorbis 320 kbps på Premium — og Squeezeboxen håndterer det native.</p> Gapless afspilning?</h3> Ja, Spotty understøtter gapless.</p> Går det i stykker, hvis Spotifys Web API ændrer sig?</h3> Ja, lejlighedsvis — Spotify roterer jævnligt OAuth-scopes eller udfaser endpoints, og Spotty får en patch-release. Hold plugin’et opdateret.</p> Kan jeg køre LMS på samme boks som mit NAS?</h3> Absolut. LMS er let (~200 MB RAM, minimal CPU undtagen under bibliotek-scanninger). At køre det ved siden af Samba eller på en homelab-SBC er det almindelige setup.</p> Er det det samme som “piCorePlayer”?</h3> piCorePlayer er en lille Linux-distribution, der gør en Raspberry Pi til en Squeezebox-kompatibel player (via SqueezeLite). Den erstatter ikke LMS — du skal stadig bruge LMS som server. piCorePlayer + LMS + Spotty er en meget almindelig 2026-stak for folk, hvis oprindelige Squeezebox-hardware endelig døde.</p> Hvad du gør, hvis din Squeezebox slet ikke vil forbinde til LMS</h2> To ting at tjekke først:</p> mDNS / multicast på tværs af dit netværk.</strong> Moderne Wi-Fi-routere blokerer ofte multicast mellem SSID’er eller til kablede hosts. Sæt Squeezeboxen og LMS på samme subnet/VLAN med multicast tilladt.</li> SlimProto-porten (3483/udp og 3483/tcp).</strong> Det er det, Squeezeboxen bruger til at finde LMS. Ikke blokeret af noget fornuftigt, men værd at tjekke, hvis du kører en stram firewall.</li> </ol> Derudover er Squeezebox-community’et stadig aktivt — forums.slimdevices.com</a> og LMS Community GitHub</a> er, hvor problemer bliver løst.</p> Squeezebox-hardware blev udfaset for femten år siden. Takket være LMS, Spotty og librespot</code> afspiller den stadig Spotify bedre end de fleste “smarte højttalere”, der sælges nye i 2026.</p> elpriser.org — danske elpriser time for time 2026-04-20T00:00:00+00:00 TL;DR —</strong> elpriser.org</a> viser den reelle elpris time for time i Danmark</strong> — ikke kun spotprisen. Den samler Nord Pool-spotprisen, din lokale nettarif (netselskab</code>), Energinets system- og transmissionstariffer, elafgiften og 25 % moms. Data kommer fra Energi Data Service</a> og opdateres dagligt, når Nord Pool offentliggør de kommende 24 timer omkring kl. 13. DK1 (Vestdanmark) og DK2 (Østdanmark). Dansksproget, gratis, intet login.</p> Hvad koster el faktisk i Danmark?</h2> “Spotprisen”, du ser på de fleste energidashboards, er kun én del af regningen. Den pris, du rent faktisk betaler pr. kWh, består af seks elementer:</p> Spotpris</strong> — sættes time for time på Nord Pool-markedet for det kommende døgn.</li> Nettarif</strong> — betales til dit lokale netselskab. Varierer efter selskab og tidspunkt (lav-, mellem- og spidslast).</li> Systemtarif</strong> — betales til Energinet, den danske TSO.</li> Transmissionstarif</strong> — betales også til Energinet.</li> Elafgift</strong> — statslig afgift på forbrug.</li> Moms</strong> — 25 % oven i alt det andet.</li> </ol> De fleste prissider viser kun det første tal. Nogle få viser ét eller to mere. Ingen, jeg kunne finde, viste alle seks time for time, for begge prisområder, med den rigtige nettarif automatisk valgt for brugerens netselskab. Det er præcis det, elpriser.org gør.</p> De to prisområder: DK1 og DK2</h2> Danmark er delt i to elprisområder geografisk — Storebælt skiller dem — og de har ofte forskellig pris i samme time:</p> DK1 — Vestdanmark.</strong> Jylland og Fyn. Mere vind-domineret.</li> DK2 — Østdanmark.</strong> Sjælland, Lolland, Falster, Møn og Bornholm. Tættere forbundet med Sverige (SE4) og Tyskland.</li> </ul> Når vinden blæser kraftigt i Jylland, kan DK1 være billig, mens DK2 er dyr. Når en forbindelse er nede, vokser forskellen yderligere. elpriser.org viser begge områder side om side.</p> Hvilket netselskab har du?</h2> Du kan ikke selv vælge dit netselskab — det afhænger af din adresse — men den nettarif, de opkræver, er en betydelig del af regningen, og den varierer med 15–25 øre/kWh i spidslast</strong> mellem billigste og dyreste, hvilket svarer til ~500–1.000 kr/år</strong> for en typisk husstand.</p> Groft rangeret spidslast-tariffer pr. 2025:</p> Område</th> Netselskab</th> Spidslast-tarif (øre/kWh)</th></tr></thead> DK1</td> RAH Net</td> ~33</td></tr> DK1</td> Trefor</td> ~37</td></tr> DK1</td> N1</td> ~46</td></tr> DK2</td> Cerius</td> ~47</td></tr> DK2</td> Radius</td> ~65</td></tr> </tbody></table> Mindre selskaber (Konstant, Nord Energi, Vores Elnet, El-net Kongerslev og andre) har egne tariffer. På elpriser.org vælger du dit eget, og den all-in time-for-time-pris tilpasser sig.</p> Du kan ikke skifte netselskab, men du kan</strong> flytte forbrug — vaskemaskine, opvaskemaskine, EV-ladning, varmepumpe — ned i lavsats-timerne. Time-grafen findes til lige præcis det.</p> Historiske yderpunkter</h2> Rekord-høj:</strong> 16,69 kr/kWh (spotpris ex. moms) i DK2, kl. 19 den 5. september 2022 under energikrisen.</li> Rekord-lav:</strong> −2,76 kr/kWh i DK1, kl. 14 den 2. juli 2023, hvor vindproduktionen overskød forbruget.</li> </ul> Negative priser er ikke en fejl: når produktionen er høj og forbruget lavt, betaler producenterne forbrugerne for at aftage strømmen. Moderne prisstyrede varmepumper og EV-ladere kan læne sig ind i det.</p> Sådan er elpriser.org bygget</h2> Statisk HTML</strong>, genskabt én gang om dagen efter Nord Pools day-ahead-auktion omkring kl. 13 CET.</li> Datakilde</strong>: Energi Data Service</a>, Energinets åbne data. Ingen API-nøgler nødvendige.</li> Strukturerede data</strong>: schema.org/WebApplication</code> og FAQPage</code> udsendes på hver side, så Google kan vise priserne direkte i søgeresultater og AI-oversigter.</li> Hosting</strong>: en lille origin bag Cloudflare. Cachebar hele døgnet; purges ved det daglige rebuild.</li> Sprog</strong>: kun dansk. Domænenavnet burde have været et fingerpeg.</li> </ul> Det hele er et enkeltsporet værktøj: ingen tracking, intet login, ingen nyhedsbrev-popover, ingen “10 måder at spare på strømmen”-lister.</p> Ofte stillede spørgsmål</h2> Hvor ofte opdaterer elpriser.org?</h3> Én gang om dagen, efter at Nord Pools day-ahead-auktion offentliggør næste døgn omkring kl. 13 CET. Intradag-justeringer vises ikke; de fleste forbrugere afregnes alligevel efter day-ahead-prisen.</p> Er prisen med eller uden moms?</h3> Med. Headline-tallet på elpriser.org er all-in pr. kWh: spotpris + tariffer + afgift + 25 % moms. Du kan folde det ud og se opdelingen.</p> Hvorfor er priserne forskellige i DK1 og DK2?</h3> Danmark har to fysisk adskilte elprisområder, forbundet via Storebælt. Når forbindelsen er fuldt udnyttet, eller når vindproduktionen adskiller sig markant mellem øst og vest, clearer de to områder på forskellige Nord Pool-priser.</p> Kan jeg se opdelingen af hver komponent?</h3> Ja. Hver time-celle kan foldes ud for at vise spotpris, hver tarif-komponent, elafgift og moms.</p> Får jeg reelt negative priser, når engrosprisen bliver negativ?</h3> Det afhænger af din kontrakt. Rene spotpris-kontrakter videregiver Nord Pools råpris — tariffer og afgift gælder stadig, så all-in-prisen kan gå svagt negativ eller bare meget lav. Fastpris-kontrakter gør ikke.</p> Hvorfor kun dansk?</h3> Data, regulering, netselskabs-strukturen og målgruppen er alle danske. En engelsk version ville oversætte kontekst, ikke indhold.</p> Hvor kommer data fra?</h3> Energi Data Service</a> (Nord Pool-spot) og Energinets tarifdata. Begge er officielle, offentlige datasæt fra den danske TSO.</p> Lille, fokuseret, intet login, ingen tracking. Sådan bør forbruger-energiværktøjer se ud.</p> winniemethmann.com — fra WordPress til Astro 2026-04-19T00:00:00+00:00 TL;DR —</strong> winniemethmann.com</a> er portfolien for en dansk madfotograf og opskriftsudvikler. I et årti var det et WordPress-site. Jeg byggede det om oven på Astro</a> med content collections</strong> (typet Markdown) i stedet for et CMS, Sharp + AVIF</strong> til billedpipelinen og Astros i18n-routing</strong> (dansk som standard, engelsk på /en/</code>). Build-tid: ~30 sekunder. Output: ~70 % mindre. Intet admin-panel, ingen plugin-opdateringer, ingen bot-prøvet login-endpoint.</p> Hvorfor væk fra WordPress</h2> For en portfolio, der opdateres et par gange om måneden, lavede WordPress for meget:</p> PHP-runtime og MySQL</strong> for et site, der i praksis er statisk.</li> Titusindvis af plugins</strong> til billedgallerier, kontaktformularer, SEO og caching — hver med sin egen opdateringskadence og sikkerhedshuller.</li> Et halvt-forket tema</strong> med patches, ingen huskede hvorfor var der.</li> Et admin-login-endpoint</strong>, der blev prøvet flere tusind gange i døgnet af bots.</li> Gentagne cache-kvaler</strong>, hver gang CDN og plugins var uenige.</li> </ul> Konkret betød det at droppe WordPress:</p> Ingen admin-panel at holde patchet.</strong> WordPress-core, plugin-opdateringer, tema-opdateringer — væk.</li> Ingen database.</strong> Indholdet ligger som Markdown i repoet.</li> Ingen login-flade, bots kan prøve.</strong> Der findes ikke en /wp-admin/</code> længere.</li> ~10× hurtigere sideindlæsning</strong> uden cache-lag.</li> ~70 % mindre samlet build-størrelse</strong> — vi skiftede håndeksporterede JPEG’er ud med AVIF med fornuftige srcset</code>-breakpoints.</li> </ul> Til gengæld mister du den ikke-tekniske redigering. I praksis betød det ingenting: ejeren var gladere for at redigere Markdown end for at kæmpe med WordPress’ blok-editor.</p> Hvorfor Astro</h2> Jeg overvejede Hugo, 11ty, Next.js static export og SvelteKit. Astro vandt på tre konkrete punkter:</p> Content collections.</strong> En typet, skema-kontrolleret måde at beskrive et portfolio-projekt som en mappe med fotos plus lidt front-matter. Buildet fejler højlydt, hvis noget ikke overholder skemaet. Intet CMS nødvendigt.</li> <Image></code>-komponenten.</strong> Astros indbyggede billedpipeline håndterer AVIF + JPEG-fallback + srcset</code> + width</code>/height</code> med en one-liner. Sharp er motoren under.</li> Islands-arkitektur — ikke relevant her.</strong> Siden har ingen interaktive komponenter, så den sender stort set ingen JavaScript.</li> </ol> Content collections, ikke et CMS</h2> Hvert portfolio-projekt er en mappe under src/content/portfolio/</code> med et front-matter-skema:</p> src/content/portfolio/ ├── 2024-kogebogs-editorial/ │ ├── index.mdx │ ├── cover.jpg │ ├── 01.jpg, 02.jpg, … └── 2023-forarets-katalog/ ├── index.mdx ├── cover.jpg └── 01.jpg … </code></pre> index.mdx</code>’s front-matter deklarerer titel, kategori, år og forsidebillede. Astro håndhæver skemaet ved build-tid via defineCollection</code></a> med et Zod-skema. Hvis et projekt mangler et forsidebillede eller har en dårlig kategori, fejler buildet.</p> Kategorier: madfotografi, opskriftsudvikling, interiør- og haveproduktion, editorial, kogebøger og mode</strong>. At tilføje et nyt projekt er mkdir</code> + cp .jpg</code> + en kort YAML-front-matter-blok. Ingen admin-UI, ingen database-migration, ingen cache at invalidere.</p> Billedpipeline: Sharp + AVIF</h2> Madfotografi står og falder med billedkvalitet. Astros <Image></code>-komponent — drevet af Sharp</a> — genererer:</p> AVIF</strong> som primært format. Stort set alle moderne browsere understøtter det nu (se caniuse</a>).</li> JPEG</strong>-fallback med matchende srcset</code>-breakpoints (320, 640, 960, 1280, 1920 px).</li> Eksplicitte width</code>- og height</code>-attributter, så der er nul layout shift, mens billederne loader.</li> loading="lazy"</code> til billeder under folden og fetchpriority="high"</code> til heroet.</li> </ul> Tal</strong>: en typisk portfolio-side gik fra ~4,8 MB håndeksporterede JPEG’er til ~1,4 MB AVIF — omkring 70 % reduktion — uden synligt kvalitetstab i de viste størrelser.</p> i18n — dansk som standard, engelsk på /en/</h2> Astros i18n-routing sidder i astro.config.mjs</code>:</p> export default defineConfig({ i18n: { defaultLocale: "da", locales: ["da", "en"], routing: { prefixDefaultLocale: false }, }, }); </code></pre> Det giver:</p> /</code> for dansk (standard, uden præfiks).</li> /en/</code> for engelsk.</li> Hvert indholds-entry deklarerer sit sprog via sin collection og filnavn.</li> <link rel="alternate" hreflang></code> og sitemap genereres fra samme kilde.</li> </ul> Indlæg og portfolio-entries uden oversættelse dukker simpelthen ikke op i det andet sprogs routing — der er ingen forkert-sprog-404.</p> Deployment og build</h2> Output</strong>: fuldt statisk, udgivet som almindelige filer bag Cloudflare.</li> Build-tid</strong>: ~30 sekunder fra koldt cache, ~6 sekunder inkrementelt.</li> Ingen server, ingen database, ingen løbende kørselstid.</strong></li> </ul> Målbare forbedringer</h2> Mål</th> WordPress (før)</th> Astro (efter)</th></tr></thead> Build / deploy-tid</td> ikke relevant</td> ~30 s koldt, ~6 s varmt</td></tr> Typisk sidestørrelse (portfolio-side)</td> ~4,8 MB</td> ~1,4 MB</td></tr> Largest Contentful Paint</td> ~2,8 s</td> ~0,9 s</td></tr> Time to Interactive</td> ~3,5 s</td> ~1,1 s</td></tr> JS sendt til klienten</td> ~220 KB</td> ~0 KB</td></tr> Plugins at holde patchet</td> 14</td> 0</td></tr> </tbody></table> Ofte stillede spørgsmål</h2> Kan en ikke-teknisk ejer stadig redigere siden?</h3> Ja, til tekstændringer. At redigere Markdown i GitHubs web-editor er i praksis lettere end WordPress’ blok-editor. For nye portfolio-projekter er workflowet: træk billeder ind i en mappe, skriv en lille front-matter-blok, commit. Er det for teknisk, kan man bolte en minimal admin på (Decap CMS, Sveltia CMS eller Keystatic).</p> Hvad med SEO efter flytningen?</h3> URL’er blev bevaret, hvor det var muligt. Manglende gamle stier omdirigeres via Cloudflare-regler. Sitemap genereres ved hvert build, og strukturerede data (Person</code>, ImageGallery</code>, Article</code>) udsendes pr. side.</p> Hvorfor Astro og ikke Hugo?</h3> Hugo er hurtigere og simplere til ren blogging, men Astros typede content collections og førsteklasses <Image></code>-komponent vandt i det her tilfælde. Til x2q.net</a> selv endte jeg senere med Zola — men til en portfolio med tung billedpipeline var Astro det rigtige valg.</p> Hvordan holdes billederne organiseret?</h3> Hvert portfolio-projekt har sin egen mappe. Git-repoet er CMS’et. git log</code> fortæller, hvornår et billede blev tilføjet, og hvorfor.</p> Er buildet deterministisk?</h3> Ja. Samme input giver bit-for-bit identisk output. Sharp er pinned i package.json</code>; det samme er Astro. CI kører på Node LTS.</p> Hvis du sidder med et WordPress-site, der laver langt mindre, end dets infrastruktur antyder, er Astro en eftermiddag værd.</p> apextowww.com — gratis apex-til-www-omdirigering 2026-04-18T00:00:00+00:00 TL;DR —</strong> DNS tillader ikke CNAME</code>-records på zoneapex (RFC 1034 §3.6.2</a>). Det er derfor hostingplatforme som Netlify, Vercel, Cloudflare Pages, Firebase og Heroku beder dig om at sætte www.eksempel.dk</code> op med en CNAME</code> og lader eksempel.dk</code> (selve apex) være et problem, du selv løser. apextowww.com</a> løser det: peg to A</code>-records og to AAAA</code>-records mod tjenesten, og den udsteder et Let’s Encrypt-certifikat til dit apex og 301</code>-omdirigerer hver forespørgsel til https://www.ditdomæne.tld/</code> — med sti og querystring bevaret. Gratis, ingen oprettelse, ingen konto.</p> Hvorfor du ikke kan sætte en CNAME på apex</h2> DNS-specifikationen er entydig: en zoneapex (det “nøgne” domæne som eksempel.dk</code>) skal have en SOA</code>-record og som regel NS</code>-records. CNAME</code> er defineret som et alias, der skal stå alene — den må ikke sameksistere med de SOA</code>- og NS</code>-records, som apex er forpligtet til at have. Derfor kan du godt CNAME www.eksempel.dk → mitsite.netlify.app</code>, men du kan ikke</strong> CNAME eksempel.dk → mitsite.netlify.app</code>.</p> Der findes workarounds, og alle er en smule akavede:</p> ALIAS- / ANAME-records.</strong> Leverandørspecifikke hos Cloudflare, Route 53, DNSimple, NS1 og andre. De virker ved at slå målet op bag kulisserne og returnere en A</code>/AAAA</code>. Fint, hvis din DNS-udbyder understøtter det; ubrugeligt, hvis ikke.</li> Fladning på udbyderniveau.</strong> Cloudflares “CNAME flattening” er præcis det, gjort automatisk.</li> Din egen altid-tændte VPS med 301 → www</code>.</strong> Det var det, jeg gjorde for flere domæner — både overkill og en lille vedligeholdelsesskat.</li> </ul> apextowww er den fjerde mulighed: en andens altid-tændte omdirigerer, driftet for dig.</p> Hvad apextowww gør</h2> Nøjagtig én ting: en 301 Moved Permanently</code> fra https://ditdomæne.tld/noget?x=y</code> til https://www.ditdomæne.tld/noget?x=y</code>.</p> TLS</strong> udstedes automatisk ved første forespørgsel via Let’s Encrypts HTTP-01-challenge. Ingen ACME-klient at køre selv.</li> IPv4 + IPv6</strong> som dual-stack fra starten. Begge record-typer er påkrævet.</li> HTTP/1.1, HTTP/2 og HTTP/3</strong> serveres. Selve omdirigeringen er lille, så protokolversion betyder mindre, men det hjælper first-paint, når omdirigeringen ligger i den kritiske sti.</li> Sti og querystring</strong> bevares, så deep links stadig virker.</li> Ingen oprettelse, intet login, ingen konto.</strong> Hvis DNS er peget korrekt, virker det bare.</li> </ul> Sådan sætter du det op</h2> Gå til apextowww.com</a> og kopiér de aktuelle IP-adresser (to IPv4, to IPv6).</li> I din DNS-udbyder: sæt A</code>-records på dit apex, der peger på de to IPv4-adresser. Fjern eventuelle eksisterende A</code>-records på apex.</li> Sæt AAAA</code>-records på dit apex, der peger på de to IPv6-adresser.</li> Sørg for, at www.ditdomæne.tld</code> stadig peger på din rigtige host (CNAME til Netlify / Vercel / Pages / osv.).</li> Vent på DNS-propagering. Besøg http://ditdomæne.tld/</code> — den skal nu 301-omdirigere til https://www.ditdomæne.tld/</code>.</li> </ol> apextowww-siden har platform-specifikke guides under /netlify-apex-domain-redirect/</code>, /vercel-apex-domain-redirect/</code>, /cloudflare-pages-apex-redirect/</code>, /firebase-hosting-apex-redirect/</code> og /heroku-apex-domain-redirect/</code>.</p> Stak</h2> Hetzner ARM64</strong>-servere for billig, strømbesparende compute. ARM64 er ~30 % billigere pr. vCPU hos Hetzner end x86 og kører omdirigereren uden at ryste på hånden.</li> Caddy-agtig automatisk TLS</strong> med Let’s Encrypt</strong> HTTP-01-challenges.</li> Dual-stack IPv4 + IPv6</strong>.</li> HTTP/1.1, HTTP/2, HTTP/3</strong>.</li> Offentligt statisk marketing-site</strong> på Cloudflare Pages, med platform-guides i hver sin URL-sti, så de rangerer uafhængigt på Google for “netlify apex redirect”, “vercel apex domain” osv.</li> </ul> Ofte stillede spørgsmål</h2> Kan jeg bruge apextowww sammen med Cloudflare DNS?</h3> Ja — men du skal have Cloudflares proxy (den orange sky) slået fra</strong> på apex’ens A</code>/AAAA</code>-records. Hvis proxien er slået til, opfanger Cloudflare forespørgslen, og Let’s Encrypts HTTP-01-challenge når aldrig frem til apextowww. Når certifikatet er udstedt og fornyes, skal du ikke bøvle videre — bare lad det være slukket.</p> Understøtter apextowww wildcards eller andre subdomæner end www?</h3> Nej. Tjenesten omdirigerer kun apex til www.</code>. Alt andet bliver liggende hos din rigtige host.</p> Hvad sker der, hvis apextowww-IP’erne skifter?</h3> Så skal du opdatere dine DNS A</code>/AAAA</code>-records. Operatøren offentliggør aktuelle IP’er på forsiden og giver varsel før ændringer. Det er fint for et privat domæne; for noget missionkritisk bør du køre din egen omdirigerer.</p> Er der rate-limit?</h3> Der er ingen publiceret hård grænse, men det er en gratis community-tjeneste. Hvis du serverer millioner af apex-omdirigeringer i døgnet, er det tid til at selv-hoste.</p> Hvorfor ikke bare bruge Cloudflares gratis plan?</h3> Cloudflares CNAME-flattening på apex er et fint alternativ, hvis hele din DNS er hos Cloudflare. apextowww er nyttig, når din DNS ikke er hos Cloudflare, eller når du vil have en host-agnostisk omdirigerer, der virker identisk på tværs af domæner.</p> Er den virkelig gratis?</h3> Ja. Marginalomkostningen pr. omdirigering på ARM64 er minimal. Ingen reklamer, ingen tracking ud over grundlæggende logs, ingen upsell.</p> Hvorfor den findes</h2> Hostingplatforme optimerer efter deres egen onboarding, ikke efter de DNS-selvfølgeligheder, der snubler enhver ny bruger. Det føltes værre at sende folk videre til en fremmeds VPS end selv at drifte én. Nu peger mine egne apex-domæner (inklusive x2q.net</a>) på apextowww, og jeg har kunnet slukke for den sidste lille omdirigerer-VPS, jeg stadig kørte af historiske grunde.</p> Det er den slags projekt, der ikke virker interessant, før du har brug for det — og så er det lige præcis det, du skal bruge.</p>

X2Q

Første kig på NVIDIA DGX Spark — hvad maskinen faktisk rapporterer (2026)

Vi troede modellen var problemet. Den var ikke.

Runde 4: at stille spørgsmålstegn ved sin egen metode</h2> Vi bad en anden model om at kritisere vores eget arbejde adversarielt — uden at være investeret i konklusionen. Den fandt to fatale metodefejl:</p>

Sådan cracker du Wi-Fi med hashcat i 2026

Trin 4 — angrib det</h2>

rockyou.txt: historien om verdens mest berømte ordliste (2026)

Fine-tuning af Whisper til danske telefonopkald: en LoRA-obduktion (2026)

Fem alternativer til pyannote: speaker diarization til telefonopkald (2026)

Baseline — EXP E (udgik tidligt)</h2> Inden F–J prøvede jeg at bygge taler-referencer fra pyannotes egne labels i databasen og køre WeSpeaker nearest-neighbour mod dem. Den nåede 88 % agreement — men er cirkulær: den bruger pyannotes labels som input. Ubrugelig som erstatning.</p>

Tre overraskelser</h2>

Apple M1 Pro vs RTX 4070 Ti til lokal AI — GPU-matmul og LLM-benchmarks (2026)

Ollama — komplet guide til lokal AI (2026)

REST API</h2> Ollama eksponerer en HTTP-API på localhost:11434</code>. Du kan bruge den direkte fra terminalen eller fra ethvert programmeringssprog.</p>

Performance-tips</h2>

Rust vs Go vs C på Apple Silicon og Linux — benchmarks på rigtig hardware (2026)

De fire benchmarks</h2>

1 — Primtalssold (primtal op til 10.000.000)</h3> Fladt bool-array-sold: skrive-tungt sekventiel hukommelsesadgang, letgrebet indre løkke. God proxy for hukommelsesbåndbredde-begrænset kode.</p>

2 — Rekursiv Fibonacci (n = 47)</h3> Ingen heap-allokering, ingen løkker — ~2,97 milliarder stakrammer. Måler rå kald-dispatch, grenforudsigelse og hvor aggressivt hver compiler inliner/optimerer dyb rekursion.</p>

3 — Matrixmultiplikation (512 × 512, f64, i-k-j løkkerækkefølge)</h3> Cache-venlig løkkerækkefølge men stadig en tæt FP-akkumulering i den indre løkke. Her betyder auto-vektorisering og eliminering af grænsecheck mest.</p>

4 — Parallel sum (100.000.000 heltal, 8 tråde)</h3> 8 POSIX-tråde (C), goroutines (Go) eller std::thread</code> (Rust), der hver summerer en partition af 0..100_000_000</code>. Tester tråd-spawn-overhead og hvor smart hver compiler håndterer den indre sum.</p>

Tre ting der er værd at forklare</h2>

BIN/IIN-opslag: kort-præfiksernes intervaller og hvordan du slår et op (2026)

Tre måder at slå et BIN op på</h2>

1. I hånden (kun netværk)</h3> Tag de første cifre og match dem mod tabellen ovenfor. Godt nok, når alt du har brug for er “er det Visa eller Mastercard?”.</p>

Transskribering af 33.000 danske voicelogs på hjemme-GPU'er — den lokale pipeline (2026)

Nulstil en Yealink-telefon til fabriksindstillinger — også uden admin-adgangskoden (2026)

Opdater Garmin-firmware og -kort i 2026 — fra WebUpdater til Garmin Express

Baseline — EXP E (udgik tidligt)</h2>
Inden F–J prøvede jeg at bygge taler-referencer fra pyannotes egne labels i databasen og køre WeSpeaker nearest-neighbour mod dem. Den nåede 88 % agreement — men er cirkulær: den bruger pyannotes labels som input. Ubrugelig som erstatning.</p>

REST API</h2>
Ollama eksponerer en HTTP-API på `localhost:11434</code>. Du kan bruge den direkte fra terminalen eller fra ethvert programmeringssprog.</p>`

1 — Primtalssold (primtal op til 10.000.000)</h3>
Fladt bool-array-sold: skrive-tungt sekventiel hukommelsesadgang, letgrebet indre løkke. God proxy for hukommelsesbåndbredde-begrænset kode.</p>

2 — Rekursiv Fibonacci (n = 47)</h3>
Ingen heap-allokering, ingen løkker — ~2,97 milliarder stakrammer. Måler rå kald-dispatch, grenforudsigelse og hvor aggressivt hver compiler inliner/optimerer dyb rekursion.</p>

3 — Matrixmultiplikation (512 × 512, f64, i-k-j løkkerækkefølge)</h3>
Cache-venlig løkkerækkefølge men stadig en tæt FP-akkumulering i den indre løkke. Her betyder auto-vektorisering og eliminering af grænsecheck mest.</p>

4 — Parallel sum (100.000.000 heltal, 8 tråde)</h3>
8 POSIX-tråde (C), goroutines (Go) eller `std::thread</code> (Rust), der hver summerer en partition af 0..100_000_000</code>. Tester tråd-spawn-overhead og hvor smart hver compiler håndterer den indre sum.</p>`

1. I hånden (kun netværk)</h3>
Tag de første cifre og match dem mod tabellen ovenfor. Godt nok, når alt du har brug for er “er det Visa eller Mastercard?”.</p>