Sådan finder vi forsker-navne med Linux-kommandoer på Windows

Illustration: Simon Väth
Linux-kommandoer i terminalen kan bruges til mange ting. Her benytter vi dem til research, hvor vi finder danske forskere, som publicerer i videnskabelige fuptidsskrifter.

Datajournalistik er et varmt emne i mit fag og det er der ikke noget at sige til - der bliver færre journalister og flere data. Kan computeren hjælpe os?

Min kollega Mads skriver om videnskabelige tidsskrifter, som ikke er helt fine i ærmet. Her er der ingen rigtig peer review, og der er vist tale om fup. Til sin artikel vil Mads gerne i kontakt med danske forskere, som har skrevet i den slags tidsskrifter. Men hvordan gør man lige det, spørger han mig.

Læs også: Ingeniøren: Over 100 danske forskere har publiceret i fuptidsskrifter 🔒

Jeg har tidligere eksperimenteret med Windows Subsystem for Linux (WSL), som giver mulighed for at bruge en Linux-terminal, med det kæmpe udvalg af smarte kommando-programmer, der medfølger, men på min Windows 10-pc, i stedet for Linux. Mon ikke det kan bruges til opgaven.

Et af de omtalte fup-forlag hedder WASET og har 'abstracts' på sin hjemmeside - sammendrag af tidsskrifternes artikler. Her står forfatternes navne, og det er dem, vi skal have fat i. Når vi først har dem, skal vi filtrere de dansk-klingende fra - men den tid, den sorg.

Windows Subsystem for Linux understøtter en række forskellige slags varianter. Vi går ind i Windows’ App-store og vælger Ubuntu, tidens populære Linux-smag.

Linux-terminal på Windows

Det er nu ikke helt rigtigt, at det er Ubuntu-Linux, der er tale om. Der er nemlig ikke rigtig nogen Linux-kerne i systemet, som benytter sig af Windows’ drivere og tjenester. I stedet får vi et terminalprogram - af varianten ‘Bash’ - og de kommandoer, som Ubuntu-terminalen byder på, sammen med dem, som kan installeres fra Ubuntus programbibliotek. Og der er mange.

Med et hack kan man endda installere grafiske desktop-programmer under WSL, med varierende held - men hvis man er nået til den yderlighed, er det nok bare bedre at lave et dual-boot-system på sin computer.

Jeg er glad og tilfreds med Windows 10, men Linux-terminalen kan jeg godt være misundelig på. Den kan bare alt muligt, som man ikke kan med Windows’ Dos-terminal - og den nye Windows Powershell er jeg ikke rigtig blevet gode venner med. Linux har jeg lidt erfaring med over årene - jeg installerede min første Red Hat for 20 år siden - så det er et sted at starte.

Når WSL-Ubuntu er installeret, startes Windows’ terminal op. Det er denne terminal, der lægger ryg til Bash-programmer, men det er også muligt at afvikle Bash i andre Windows-baserede terminalprogrammer.

Kommandoer gør arbejdet

Nu kan vi gå i gang med opgaven. Mit Windows-drev C:/ kan findes i Bash med kommandoen

$ cd /mnt/c

Cd betyder change directory, ligesom i Dos. Hvis man har et langt og indviklet navn på en mappe, kan man bare skrive de første par bogstaver, og så trykke på tabulator-tasten - så skriver Bash selv navnet færdigt. Smart i en fart.

Jeg er ikke nogen haj til Linux-kommandoer, så jeg søger på nettet efter eksempler på det, jeg har til hensigt at gøre, og prøver mig lidt frem og tilbage. Resten af fortællingen herunder har ikke alle mine mislykkede forsøg med, men så svært var det nu hellere ikke. Det er heller ikke nødvendigvis den smarteste løsning jeg har fundet, men det går stærkt, så det gør ikke så meget.

Nok snak, lad os komme i gang. Vi navigerer hen til en ny mappe med cd og snupper en kopi af websitet, som det problematiske tidsskrift-forlag står bag. Vi downloader websitet med kommandoen wget, som kan downloade webresurser. Det ser sådan ud:

$ wget --mirror -R gif,jpg,png,xml,json https://waset.org

‘mirror’-flaget betyder, at vi ønsker at spejle websitet - altså lave en lokal kopi. ‘R’ står for reject, og betyder at vi ikke vil downloade resurser, hvis navn slutter med de filkoder, vi har angivet. Wget kigger ikke på selve filtypen, binært set, så hvis resursen ikke har nogen filkode, bliver den downloadet alligevel.

Download med wget, filtrer med grep

Vi sætter wget i sving, og kommandoen downloader i timevis...

Efter fem gigabyte stopper vi kommandoen, med Ctrl+C (der stopper alle slags kommandoers afvikling), for nu må det være nok. Vi skal ikke finde én specifik oplysning, men gennemtrawle for danske navne, og mon ikke fem gigabyte skulle være nok som udgangspunkt.

Næste skridt er at finde tekstlinjer i filerne, der indeholder forfatternavnene. Ved at kigge i en html-fil, finder vi forfatternes navne i en linje som denne:

<div class='block'><b>Authors:</b> <div class='presenter'><a href='/abstracts?q=Nishit L. Sanil' >Nishit L. Sanil</a>, <a href='/abstracts?q=Raza M. Khan' >Raza M. Khan</a></div></div>

Vi kan bruge Linux’ grep-kommando til at finde alle disse linjer med. Grep benytter regular expressions til at finde linjer i tekstfiler. Det ser sådan ud for os:
$ grep -Erh "<div class='presenter'>.*</div>$" * > ../ud1.txt

Der er tre flag til kommandoen, E, r, h, og dem kan man bare smaske sammen foran en enkelt streg. E betyder, at vi bruger moderne regular expressions, r står for ‘recursive’ og gør, at grep også kigger i underliggende mapper, og h - hvad gør h?

Bash har en indbygget manual, der giver en nødtørftig forklaring af kommandoerne. Den kaldes med:

$ man grep

Hvis vi bladrer lidt ned i manualen, står der følgende:
-h, --no-filename
Suppress  the  prefixing  of file names on output.  This is the default when there is only one file (or only standard input) to search.

Grep skriver nemlig som udgangspunkt, hvor i en fil den har fundet et match, men det skal vi ikke bruge - vi skal bare have den fundne streng. Man skal også lige være obs på, at kommandoernes flag er case-sensitive, som man siger på programmør-dansk - så stort H gør noget helt andet.

Efter flagene angiver vi streng-mønstret

"<div class='presenter'>.*</div>$"

Det betyder, at vi vil snuppe teksten, der står inde i det givne div-element i html-dokumenterne.

Derefter kommer der en asterisk *, som betyder ‘søg i alle filer’, og kommandoen slutter med > ../ud1.txt, som betyder: Skriv uddata til filen ud1.txt, der befinder sig i den overliggende mappe - så der ikke bliver for meget rod i mappen, og vi kan kigge resultatet igennem bag efter.

Grep bruger lidt til på sit arbejde, og så kommer Bash-prompten tilbage igen. Grep skriver en linje, for hver, den har fundet, så vi kan tælle antallet af linjer med kommandoen wc, word count (der tæller linjer, når kommandoen udstyres med flaget -l):

$ wc -l ud1.txt

Vi kan også kigge på starten af filen med kommandoen head:

$ head ud1.txt
<div class='block'><b>Authors:</b> <div class='presenter'><a href='/abstracts?q=Roman Kalvin' >Roman Kalvin</a>, <a href='/abstracts?q=Anam Nadeem' >Anam Nadeem</a>, <a href='/abstracts?q=Saba Arif' >Saba Arif</a></div></div>

De fundne linjer ser ud som html-klumpen ovenfor, og nu starter vi med at slette alle html-tags.

Slet med sed, sorter med sort

Her bruger vi sed-kommandoen, som kan behandle en strøm af tekst på forskellige måder. Lidt søgning på nettet fører til denne løsning:

$ sed "s/<[^>]+>//g" ud1.txt > ud2.txt

Det første argument er et regulært udtryk, ligesom med grep. ‘s’ står for substitute, erstat, som i vores tilfælde erstatter det fundne med ingenting - med andre ord sletter den delstrenge, som passer til udtrykket, der siger følgende: ’Noget, der starter med en <, efterfulgt af noget, som ikke er >, og som afsluttes med en >’. ‘//g’ betyder globalt, dvs. alle linjer.

Summa summarum: Alle html-tags slettes. Dem skal vi ikke bruge. Nu ser resultatet sådan ud:

$ head ud2*
                Authors: Roman Kalvin, Anam Nadeem, Saba Arif
                Authors: Barenten Suciu

(Man behøver ikke skrive hele filnavnet - en stjerne kan gøre det ud for halen i navnet.) Nu skal vi have slettet "Authors:" og have lavet komma om til linjeskift, så vi får ét navn pr. linje. Vi udfører begge dele i en glidende tackling med kommandoen:
$ sed 's/Authors: //' ud2.txt | tr ',' '\n' > ud3.txt

'Pipe'-symbolet | sender uddata fra sed-kommandoen over i tr (for 'translate'), som udskifter komma med linjeskift.

Den er dog ikke helt i vinkel. Der er lidt snask i starten af nogle af linjerne:

$ head ud3.txt
                Roman Kalvin
 Anam Nadeem
 Saba Arif

Det fjerner vi med den noget uigennemskuelige kommando:
$ awk '{$1=$1};1' ud3.txt | sort | uniq > ud4.txt

Awk-kommandoen trimmer vores linjer, og vi 'piper' uddata videre til sort, der sorterer linjerne alfabetisk, og videre til uniq, der fjerner dubletter.

Match med danske efternavne

Nu skal vi finde dansk-klingende navne blandt dem på listen.

Ankestyrelsens hjemmeside finder vi en liste over såkaldt frie efternavne, som er de efternavne, der bæres af mere end 2.000 personer. Der er 196 navne på listen, og mon ikke det er et meget godt net i forhold til at finde navne, især da Danmarks Statistik fortæller os, at de blot 20 mest brugte navne dækker knap to millioner danskere.

Her begår jeg den frygtelige fejl at bruge Windows-programmet Notepad++, til at gemme tekstfilen med efternavne, med CR-LF som linjeafslutningstegn, mens Linux og Unix bruger LF. Det tager et stykke tid for mig at finde ud af, at det er det, der gør, at jeg ikke kan få grep-kommandoen til at makke ret.

Senere finder jeg ud af, at jeg kan ændre linjeskift i Notepad++ med menuen Rediger > Linjeskiftkonvertering, som klarer konvertering mellem Windows og Unix. Herefter går det godt.

Vi gemmer efternavnene i en tekstfil, med det rigtige LF-linjeafslutningstegn, og grep'er igen:

$ grep -wFf navne.txt ud4.txt > ud5.txt

Denne udgave af grep finder ordene - efternavnene - i den første fil, når de optræder i den anden fil. Flaget 'w' kigger kun efter hele ord, og flaget 'F' slår regular expressions fra, så der søges på eksakte strenge.

Det giver en liste, der starter således - vi har dog ændret navnene lidt.

A. Buk
A. C. Jensen
A. F. Petersen
A. Vang
Alex Michelsen

Vi gjorde det samme med hjemmesiden for forlaget OMICS, og de fundne navne indgik i min kollega Mads' videre research.

Tekst i PDF'er

I midlertid er der også en del artikler i PDF-format i det downloadede materiale fra WASET. Det kunne være interessant også at kigge på navne i disse filer. Disse PDF-dokumenter befinder sig i en bestemt mappe.

Inde i mappen afvikler vi dette shell-script:

for file in *; do
  fileinfo=$(file $file)
  if [[ $fileinfo =  *"PDF"* ]]; then
    newfilename=$file.txt
    echo ${newfilename}
    pdftotext  $file ${newfilename}
  fi 
done

(I Bash kan man bare kopiere scriptet ind, og så kører det lystigt.)

For-linjen gennemløber alle filer i mappen. Fileinfo-variablen sættes til uddata fra file-kommandoen, som skriver oplysninger om hver enkelt fil. Hvis den indeholder noget med 'PDF' udføres if-sætningen.

Kroppen i if-sætningen laver et nyt filnavn, som ender med '.txt'. Derefter udtrækkes teksten i PDF'en med kommandoen pdftotext.

De fremkomne tekstdokumenter indeholder linjer som:

Authors : Mahvish Anjum

– og så kan vi bruge de samme teknikker som tidligere til at udtrække og filtrere navnene.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (20)
Carsten Olsen

Vi går ind i Windows’ App-store og vælger Ubuntu

På Chrome/71.0.3578.21 kan man som noget nyt vælge at bruge Linux/Debian apps. Alle de kommadoer der bruges i artiklen er unix commandoer og virker derfor osse i Debian.

Hvis man skal installere apps gøres det med "sudo apt-get" (Det er osse det samme i ubuntu). Man kan osse trykke CTRL-C CTRL-V. (copy paste til/fra CB/Debian)
Man skal dog lige huske at holde SHIFT nede i terminalen. Mus højreklik i terminal giver CTRL-V

Alle filer i ~/ (Min Hjemmemappe) Ligger osse inde i "filer" på Chromeos skrivebordet. Man skal huske at tage backup af sit hjemme katalog på f.eks. Drive (Normalt tages der ikke Backup af en Chrombook)

Povl H. Pedersen

WSL er vel bare en virtuel maskine med nogetVMWare Unity lignende integration.

Så det du laver er ikke at du laver noget under Windows, du laver noget i en virtuel maskine så vidt jeg forstår det. Ligesom du kan få et Windows 95 subsystem.

Hvis du vil have noget der kører under Windows, så er det CygWin du skal have fat i. Her kører alle programmer native under Windows, men er linket til nogle CygWin libraries.

Magnus Jørgensen

Windows NT kernen's Linux Kerne "emulering" performer faktisk rigtigt godt i forhold til native Linux kerne, dog med undtaget for filsystemet som performer væsentligt dårligere. De arbejder vist stadig på at forbedre filsystem performance.

Torben Jensen

Under Windows skal alt pakkes ind i GUI, og du skal finde eller købe en applikation for at udføre simple ting.
Så hvis denne artikel kan lære Windows brugere en anden simpel metode at udføre noget hurtigt, så god vind.
Gennem mange år var det Cygwin det kunne det samme.

De små UNIX style kommandoer er bygget til at gøre en enkelt opgave nemt, hurtigt og effektivt, og der er mange af dem.
Linux er bygget til at alt klare via command prompt, sekundært kan du vælge at starte en GUI desktop.
Nogen vil mene det ikke er brugervenligt, alt det er meget svært, det er jo ikke GUI, ja men det er meget effektivt.

Sune Marcher

Der har været native Windows-versioner af samtlige tools du anvender i årevis (Cygwin eller MinGW, der ikke har alt det ekstra Cygwin bras med), så det er altså ikke først med WSL at man kan de her ting.

WSL er ret fedt, og hvis man i forvejen bruger det til mere komplicerede ting, ligger det lige til højrebenet... men ellers er det måske en smule overkill i forhold til fx MinGW :-)

Til folk der stadig sidder fast i grep, kan jeg anbefale ripgrep – den er ekstremt hurtig, har native binaries til Linux, Windows og macOS, og har en masse quality of life indbygget, så man typisk ikke behøver en masse argumenter. Den indlæser bl.a. som standard .gitignore filer, hvilket er super praktisk hvis man vil greppe over en hel kodebase.

<kæphest>
PS: der har ikke være DOS i Windows siden 9x-dagene. Ja, der er sammenfald med standard-kommandoerne, men ellers har command shell ikke noget med DOS at gøre.
</kæphest>

Lars Bjerregaard

Kan varmt anbefale WSL, det fungerer fremragende, inden for de givne rammer.

De givne rammer er, at du ikke skal bruge en Linux kerne (hvilket du temmeligt sjældent skal), og ikke skal køre permanente services, og ikke skal køre GUI programmer. Så hvis dit behov er at køre alle de mulige og umulige (non-GUI) programmer som findes til Linux, men fra en Windows maskine, så er WSL helt overlegent. Langt slankere og hurtigere end et VM, og klart hurtigere og meget smidigere at administrere end Cygwin og MSYS.

Det man kører i WSL er native linux programmer, administreret af native Linux package manager. Det er ikke Windows oversættelser, og kører ikke igennem wrappere. Hvis ens primær maskine er Windows, og man kan lide/er fortrolig med Linux/Unix, og ikke har behov for en selvstændig Linux maskine, så behøver man ikke rigtigt kigge andre steder hen end WSL.

Der er også flere distributioner der kan køre under WSL nu, klar til installation fra Windows Store - Ubuntu, Debian, Kali, Suse, etc.. Læs mere her: https://docs.microsoft.com/en-us/windows/wsl/faq

Igen - varmt anbefalet.

Gregor Giebel

Jeg tror at den indsnævring til danske navne er et problem i den videnskabelige verden vi lever i. Jeg arbejder på DTU Vindenergi, og vi er 250 mennesker fra 39 forskellige nationaliteter, dvs danskere er bare den største mindretal. Mange af vores medarbejdere (mig selv inkluderet) har efternavne som er temmelig unikke i Danmark, og bliver derfor ikke fanget i denne search.
Til gengæld kunne man vel bruge personalelisterne af de danske universiteter med lignende metoder, og så få et meget bedre match.

Men tak for en sjov artikel - jeg har lave noget automatisering af min første hjemmeside med awk og cygwin. Siderne var skrevet i hånden i Notepad+ i 1996 - dengang var det HTML2. :)

Sune Marcher

Langt slankere og hurtigere end et VM, og klart hurtigere og meget smidigere at administrere end Cygwin og MSYS.


Hvordan er WSL - i tilfældet hvor man kun bruger en lille håndfuld tools - hurtigere og smidigere end fx MinGW?

Du har ret i at WSL ikke er emulering, men der er trods alt et syscall oversættelseslag og kernel object bookkeeping... derudover fylder "en håndfuld" tools et par megabyte og kan pakkes ud fra en zipfil, hvorimod Ubuntu for WSL er et par hundrede megabytes, og kræver installation et cetera.

Misforstå mig ikke, jeg synes WSL er super fedt, både fra teknologi- og usability-perspektiver, og jeg er stor fan af package managers fra Linux distroer.

Men vi har altså kunne gøre de her ting - komfortabelt - på Windows i årevis :)

Baldur Norddahl

Hvordan er WSL - i tilfældet hvor man kun bruger en lille håndfuld tools - hurtigere og smidigere end fx MinGW?

WSL er LXC/LXD https://en.wikipedia.org/wiki/LXC men med en Windows kerne i stedet for Linux kernen.

Det er ekstremt nemt at installere og derfra kan man installere stort set hvad som helst med "apt". Inklusiv grafiske applikationer, som bare kræver at du også installerer en X11 server.

Programmerne hentes direkte fra Ubuntus normale distribution. Alt er således tilgængeligt direkte og uden forsinkelse. Det inkluderer alle programmer og bugfikses. Det er dog ikke givet at alle programmer fungerer, hvis de har brug for noget i Linux kernen som WSL ikke oversætter perfekt til Windows kernen.

Ud fra et teoretisk synspunkt, vil jeg tro at MinGW og WSL har det samme overhead. Du har nogle programmer der er skrevet til ét API (Linux kernens) men som via transformation skal virke under et andet API (Windows kernens). Om dette sker via et bibliotek der er linket ind eller om det sker direkte i Windows kernen gør næppe den store forskel.

Det er sikkert rigtigt at WSL fylder mere. Men er hundrede MB ikke temmelig ligegyldige i året 2018?

Tania Andersen Journalist

Hej Gregor - selv tak :-)

Ang. fangst af navne, så drøftede jeg og min kollega Mads Nyvold, der har skrevet den læsværdige serie af artikler om emnet til Ingeniøren, noget af det samme, som du er inde på.

Så vidt jeg ved, er der ingen tilgængelige lister af alle danske forskere. Det betyder, at man skal bruge telefonlister fra danske forskningsinstitutioner, som der er ganske mange af.

Det vil igen sige, at man skal downloade og parse html-sider, ofte spredt over flere “resultat-sider” fra et stort antal websites, hvilket igen vil medføre en meget stor arbejdsbyrde - måske flere dages arbejde, så vidt jeg kan bedømme. Som nævnt i artiklen ønsker vi blot at kaste et net af en hvis finkornethed - og her fungerer Unix/Linux-kommandoerne ganske hurtigt og godt til vores formål.

Jeg skal også for en god ordens skyld nævne, at min kollega Jakob Møllerhøj udtrak flere oplysninger fra de pågældende forlags hjemmesider, bl.a. om danske forskere, som ikke altid korrekt var angivet som “editors” i forbindelse med de tvivlsomme tidsskrifter, ved hjælp af et Python-script.

Sune Marcher

Hvordan er WSL - i tilfældet hvor man kun bruger en lille håndfuld tools - hurtigere og smidigere end fx MinGW?

WSL er LXC/LXD https://en.wikipedia.org/wiki/LXC men med en Windows kerne i stedet for Linux kernen.


Linux containers er i stor grad isolation via namespacing - WSL har et oversættelseslag mellem Linux syscalls og NT kernen. Der er nogle fundamentale forskelle i hvorden visse ting håndteres på kernel niveau, hvilket kræver noget ekstra bookkeeping og oversættelse frem og tilbage. Jeg har ikke set tal på hvor meget det betyder - men det er naturligvis ikke gratis.

Hvis man kan lide lowlevel stuff, er der spændende Microsoft blogposts om WSL, man kan fx starte med Windows Subsystem for Linux Overview.

Jeg har intet imod en passende mængde overhead, når jeg får noget for det - men i tilfælde hvor jeg kun har behov for en håndfuld tools, får jeg ikke rigtigt noget ud af WSL. En ting er syscall og bookkeeping overhead, der sandsynligvis i de fleste workloads er minimalt - men så jeg kiggede var der stadig et ret væsentligt overhead på I/O delen, bl.a. fordi Linux-style fil metadata skal gemmes som ekstra NTFS alternate stream data.

Ud fra et teoretisk synspunkt, vil jeg tro at MinGW og WSL har det samme overhead. Du har nogle programmer der er skrevet til ét API (Linux kernens) men som via transformation skal virke under et andet API (Windows kernens). Om dette sker via et bibliotek der er linket ind eller om det sker direkte i Windows kernen gør næppe den store forskel.

Bumbum, om det gør en forskel må være op til benchmarks. Men MinGW linker (så vidt jeg husker) mod en libc der benytter native NT API'er, i stedet for at kræve oversættelse og bookkeeping på syscall niveau. Som et helt reelt spørgsmål, gad jeg godt vide hvad der performer bedst - malloc implementeret som brk syscall, der skal oversættes, og glibc heap manager på toppen af det, eller en libc implementering der kalder NT HeapAlloc med low fragmentation heap mode enabled.

Det er sikkert rigtigt at WSL fylder mere. Men er hundrede MB ikke temmelig ligegyldige i året 2018?


Et par hundrede megabyte her og der...

Igen, hvis man får ekstra value for the overhead, så fint. Hvis jeg skulle køre et cross-compilation setup, havde brug for applikationer med hyppige updates, eller en del andre scenarier, ligger WSL lige til højrebenet.

Men jeg er lidt træt af den gængse idé om at overhead generelt er ligemeget. Ikke ment som at vi alle skal tilbage til at skrive i assembly eller C, men hvis folk nu ikke bare klaskede lag på lag af dårlige abstraktioner og overhead sammen, så holdt vores laptops og mobiletelefoner måske batteri en smule længere, og performede lidt bedre.

Baldur Norddahl

Men jeg er lidt træt af den gængse idé om at overhead generelt er ligemeget.

Jeg mener bestemt ikke at overhead er ligemeget. Men i dette tilfælde er jeg mere bekymret over hvor meget det fylder i RAM samt CPU overhead. Så vidt jeg kan se, så er overhead ved WSL minimalt for de to parametre. Programmerne bruger mere eller mindre det samme, som var det native windows programmer.

Prisen er naturligvis ikke nul. Men hvis nu tager dit eksempel med "malloc", så er det næppe noget der er målbart i praksis ved de fleste programmer.

Sune Marcher

Jeg mener bestemt ikke at overhead er ligemeget. Men i dette tilfælde er jeg mere bekymret over hvor meget det fylder i RAM samt CPU overhead. Så vidt jeg kan se, så er overhead ved WSL minimalt for de to parametre. Programmerne bruger mere eller mindre det samme, som var det native windows programmer.


Overhead er muligvis minimalt, men i de scenarier hvor jeg ikke får noget i bytte, ser jeg stadig ikke grund til at introducere nogen form for ekstra overhead.

Filsystem overheadet er til gengæld til at tage og føle på – et par eksempler fra Phoronix: "compile bench" giver 6.38MB/s under Ubuntu/WSL, 580.9 MB/s under native Ubuntu. PostgreSQL pgbench giver næsten dobbelt så mange TPS på en native Ubuntu som under Ubuntu/WSL.

Det havde naturligvis været en fordel hvis der også var medtaget native Windows versioner af benchmarks, så det blev demonstreret at det er det ekstra WSL overhead der sløver, og ikke bare "NTFS sucks" ;-) – men der er ganske interessante kommentarer på GitHub issuet om sløv WSL I/O performance.

Igen-igen: WSL er smart, der er situationer hvor det giver mening, et cetera... men til en håndfuld curl/wget/grep/sed/... tools er det alligevel lidt nemmere at unpacke en lillebitte zipfil, du får 100% native performance, du er ikke begrænset til Win10 som host, og du skal ikke til at installere non-base applikationer enkeltvis.

Log ind eller Opret konto for at kommentere
Pressemeddelelser

Welcome to the Cloud Integration Enablement Day (Bring your own laptop)

On this track, we will give you the chance to become a "Cloud First" data integration specialist.
15. nov 2017

Silicom i Søborg har fået stærk vind i sejlene…

Silicom Denmark arbejder med cutting-edge teknologier og er helt fremme hvad angår FPGA teknologien, som har eksisteret i over 20 år.
22. sep 2017

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 2017
Jobfinder Logo
Job fra Jobfinder