Bjørn Engsig

Helsingør Kommune i kovending: Google er ikke uundværlig i folkeskolen

Jeg bruger et godt mix af det hele, dog så vidt muligt uden Windows. Jeg undgår ikke google, men tænker over brugen.

  • Linux på mine PC'er
  • Betalt google docs (hedder vist suite) på eget domæne til privat kalender, tekst m.v.
  • Mail på egen domæne hos proton
  • Duckduckgo som søgemaskine til 90% af søgninger
  • Telefon/tablet med LineageOS og gapps
  • Betalt kort/GPS og kun google maps i nødstilfælde
  • Endnu en krypteret tablet med LineageOS og uden gapps, som jeg dog i praksis sjældent anvender.

Men jeg er heller ikke hysterisk og bruger f.eks. ikke tor.

3. februar kl. 14:58
Helsingør Kommune i kovending: Google er ikke uundværlig i folkeskolen

Lad os nu lige være lidt pragmatiske her. Uanset hvad, så koster det penge at have IT, og det bliver på ingen måde gratis af open source. Hvis det er en alternativ cloud løsning, skal den jo holdes ved lige, der skal stå en server et sted, der skal være backup osv. Må noget sådant hostes hos Amazon i Amsterdam? Hos en måske Billigere Baggårds Bix i Bogense? Eller Skole Zystems i Shenzhen? Eller skal den stå i kælderen?

Vi kan hurtigt finde nogle fjender som Google, Microsoft, Amazon, NSA, WhatsApp eller hvad ved jeg, men i alle tilfælde er det vigtigste nok at lære eleverne at være opmærksomme. Uanset om der står en server i kælderen, eller den ligger et ukendt sted i skyen skal eleverne eksempelvis lære bare at skrive navn og klasse og ikke CPR nummer og adresse på deres danske stil. Så vil de måske også forstå, at den samme praksis er fornuftig, når de går ind på en af de mange andre hjemmesider og apps, de jo alligevel anvender.

Jeg ville personligt føle mig mere sikker ved at anvende en Google løsning end at sætte min Windows PC til et microsoft netværk med en server i kælderen og en skole fuld af teenagere for det er jo det, der er det reelle alternativ og ikke NextCloud eller LibreOffice i et Linux miljø.

2. februar kl. 13:37
'Sommerhat20' som standardkodeord: Hundredtusinder af TDC-routere kunne overtages

Med adgang til mindst et par håndfulde maskiner med port 22 åben kender jeg både til de op mod tusindvis af banale forsøg på at gætte et kodeord og til hvordan jeg sikrer mig. Jeg vil også meget nødig have yousee til at mene, de skal gøre noget ved det. Hjemme klarer min egen router bag yousee's bl.a. den slags. Ret skal være ret, og jeg synes faktisk yousee gør det fint ved at man kan lave en DMZ, så vi nørder kan gøre, hvad vi vil.

30. september 2020 kl. 21:26
60 statslige domæner sylter obligatorisk beskyttelse mod mail-svindel

Jeg kører min egen mail-server, og for noget tid siden var det pludselig en masse spam fra mange ny-oprettede domæner, som havde helt korrekt spf, dkim, dmarc. Det bliver selvfølgelig fanget af diverse blacklists indenfor nogle få dage til en uge, men der må have nået rigtig meget spam frem worldwide inden da.

10. august 2020 kl. 13:10
C++ er svaret - men hvad var egentligt spørgsmålet?

Thjaa, tråden er kommet langt væk fra C++, men er da stadig interessant læsning.

@Jens D Madsen, når du skriver:

Hvis du ser på mine beskrivelser af hardware, så er det noget helt andet end en PC. Selv en computers registre er på harddisken, og computere har ingen ram, andet end cache.

så er det godt nok meget forskelligt fra de servere, hvor Oracle og andre tilsvarende produkter kører. Selvom de afgjort heller ikke er PC'er (hvilket jeg ikke på noget tidspunkt har antydet) så er de meget traditionelle med nogle CPU'er med cache, RAM, netværk, I/O, diske osv.

Du skriver også - helt korrekt - at de velkendte relationelle databaser ikke er realtid. Nej, sådan er de ikke designet. De er designede som flerbruger systemer, i virkeligheden helt i samme ånd som f.eks. mainframes og det tidlige VMS hardware, jeg har linket til et godt stykke oppe. Så vi kan ikke garantere eksekveringstider, men vi kan bygge meget komplekse systemer, hvor vi går efter regler, som at et vist antal procent (måske 95, 98, 99) af ekseveringerne af en bestemt operation er hurtigere end en bestemt grænse. Uanset om du spørger telefonselskaber, banker, detail handel, internet forretninger, produktionsvirksomheder, flyselskaber, eller stort set hvilken som helst anden type kunder, så er det det, der efterspørges. Det er så systemer, der kan understøtte tusindvis, ti-tusindvis, ja hundred-tusindvis af samtidige brugere. Det er det vi kalder skalering, og du har allerede nævnt, at en af de mange værktøjer vi har i kassen til at skalere er at lade flere systemer arbejde sammen. I princippet er det nemt: Hvis en operation tager 1ms på en CPU, så kan en server med 100 CPU'er klare 100.000 operationer per sekund.

Men kom nu på banen med konkrete eksempler på systemer, hvor den hardware du beskriver anvendes.

30. juli 2020 kl. 13:49
C++ er svaret - men hvad var egentligt spørgsmålet?

@Jens D Madsen: Jeg taler overhovedet hverken om filformater eller harddisk. Jeg forsøger blot at sige, at Oracle ikke kunne skrives med en generisk hardware abstraktion. Af gode grunde kan jeg ikke fortælle detaljer om vores software; men jeg har givet en række eksempler, der er lidt i den rigtige retning, og som viser, at det er nødvendigt for os at lave hardware specifikke tilpasninger.

Antallet af computer og operativ system typer er i dag mindre, end da jeg startede i slut firserne, men dengang som nu var netop hardware tilpasning en vigtig del af vores software.

28. juli 2020 kl. 18:28
C++ er svaret - men hvad var egentligt spørgsmålet?

Sådan en gang til for Prins Knud, skal det forstås som at I ikke bruger en eller anden standard SQL motor (efter hvad man nu kan lide), men har hårdkodet jeres helt egen DB motor?

Jeps, vi skriver vores egen... Jeg har arbejdet for Oracle i 25+ år!

28. juli 2020 kl. 18:13
C++ er svaret - men hvad var egentligt spørgsmålet?

Normalt er ikke mening at brugeren skal tænke på computerens L1, L2 og L3 cache. Så er et eller andet galt.

Som du måske har gættet, så er jeg software ingeniør...

Og uden at jeg skal komme helt i detaljer med, hvordan vores software er opbygget, kan jeg dog sagtens fortælle om en situation, hvor kendskab til størrelsen på cpu cache er relevant: Vi forsøger at lave samspil mellem compiler og linker, således at objekter vi ved anvendes "samtidig", anbringes så de med stor sandsynlighed kan være i cachen; det kan (så vidt jeg husker) give mindst en faktor ti forbedring i access tiden. Noget andet hardware vi også tager hensyn til i vores software design er forskellige C-states, og så som allerede nævnt numa eller flat memory. Alt dette er forfinet gennem flere årtier og samtidig fulgt med udviklingen i hardware, og der er absolut intet "galt". Og mit hovedsynspunkt er stadig det samme: Alt dette kan vi kun gøre, fordi vi tilpasser softwaren til den aktuelle hardware; det ville ikke fungere optimalt såfrem vi blot anvendte en given compilers abstaktion af hardwaren.

27. juli 2020 kl. 18:31
C++ er svaret - men hvad var egentligt spørgsmålet?

Nu kender jeg ikke dit setup, men vil det ikke være smartest at lade selve databasemotoren (med mindre det selvfølgelig er lige præcis det du laver) håndtere samtidighed?

Det er det, jeg laver, og det er præcist det vi gør. Hele min argumentation på den del er, at vi kun kan gøre det (så det performer), hvis vi på hver eneste platform udnytter kendskab til hardware. Jeg tror ikke, det kan lade sig gøre med en generisk hardware abstraktion.

@Jens D Madsen: Du er stadig ekstremt teoretisk. Kan du ikke komme med nogle faktiske eksempler på software, hvor din teoretiske udredning er det, som får det hele til at fungere (og performe) i praksis?

Og når jeg omtaler L1, L2, L3 cache og numa (som du ikke svarer på), er det naturligvis hardwaren.

27. juli 2020 kl. 17:03
C++ er svaret - men hvad var egentligt spørgsmålet?

Det er nok spørgsmålet på det svar!

Jeg forstår udmærket ironien i det svar (eller var det et spørgsmål?).

Men jeg mener afgjort ikke, at jeg har spildt mit arbejdsliv gennem de sidste 30+ år på at arbejde med netop den slagt problemer, som er skitseret i mine indlæg.

I mit spæde arbejdsliv, da objektorientering generelt og C++ specifikt var det nye og hotte, fik jeg overbevist min daværende arbejdsgiver om, at jeg skulle på et C++ kursus. Det var meget lærerigt, idet jeg ret hurtigt indså, at det mest var kejserens nye klæder. Og ingen har i de forløbne 30 år kunnet overbevise mig om det modsatte.

Mit eksempel med den røde bil er ikke (helt) taget ud af den blå luft. Jeg havde vel for mindst 25 år siden en performance opgave hos en belgisk kunde, hvor man jo har to sprog, så applikationen skal skrive alle prompts på enten flamsk eller fransk. Og programmøren havde skrevet noget i retning af:

  1. if employee.language() = 'French' then
  2. print "bon jour"
  3. else
  4. print "goede morgen"
  5. end if;

som blev udført hver gang noget skulle skrives på skærmen. Hvad programmøren ikke vidste var, at language() metoden i employee klassen spurgte databasen hver gang.

Det mest morsomme ved den historie var at den gentog sig i en lidt mere avanceret form omkring 10 år senere i Canada.

26. juli 2020 kl. 12:04
C++ er svaret - men hvad var egentligt spørgsmålet?

@Jens D Madsen:

Du bliver ekstremt teoretisk, og det kunne være rart at høre nogle praktiske eksempler på applikationer eller programmer, der (kun) virker via de abstraktioner, du omtaler, og hvor programmøren således får noget forærende ved at skrive C++.

Mine eksempler er alle meget praktiske, og de anvendes i hundreder af tusindvis af systemer dagligt. Et enkelt eksempel er håndtering af kreditkorttransaktioner, som er en meget typisk oltp applikation. Den har en database (som er mit felt), hvor hundreder eller tusinder af processer eller tråde skal arbejde sammen og en del af dette foregår via shared memory. Det kan efter min bedste overbevisning kun gøres fordi programmørerne er enige om semantikken og eksplicit anvender hardware mekanismer på det aktuelle hardware. Bl.a. kan det være vigtigt for programmøren at have kendskab til om memory er numa eller ej eller til størrelsen og placeringen af L1, L2 eller L3 cachen. Det vil på ingen måde kunne skrives, hvis man overlader forståelsen og abstraktionen til compileren.

Og så for lige at vende tilbage til mit første indlæg: Der er rigtig langt fra tjenerens håndterminal, hvor du holder dit kreditkort hen for at betale, eller fra den hjemmeside, hvor du betaler for en vare, og til databasen der skal klare kreditkorttransaktionen. Og det er præcist den meget lange vej, der efter mine 30+ års erfaring på området nemt bliver helt unødigt kompliceret, lang eller resourcekrævende, når de anvendte programmeringssprog bliver for abstrakte og for indkapslende. Det er præcis der lag, på lag, på lag blive decideret kontraproduktivt. Og det er præcis der objektfokuserede sprog som C++ nærmest opfordrer til den lag på lag tankegang. Hvis du vil kende bilens farve, så spørg mig. OK, men hvad koster så det? Øhh, er det dig eller mig, der kender bilens farve?

26. juli 2020 kl. 11:46
C++ er svaret - men hvad var egentligt spørgsmålet?

Læs http://h30266.www3.hpe.com/odl/axpos/opsys/vmsos84/5841/5841pro_018.html som lidt historisk ganske præcist beskriver, hvad jeg mener. Og bemærk, at der flere gange står "read your compiler manual".

24. juli 2020 kl. 13:38
C++ er svaret - men hvad var egentligt spørgsmålet?

Derfor virker konstruktionen ikke deterministisk. [...]. Typisk ender det hele med at ikke fungere.</p>
<p>Metoden er ganske enkelt forkert. Jeg anvender i det som jeg beskriver ikke låsning af hardware.

Mit eksempel viser med al tydelighed, at rækkefølgen sagtens kan være ligegyldig. Hvis to processer/tråde med adgang til shared memory skal holde styr på, hvor mange gange "noget er sket", skal de begge blot udføre ++(*p). Det er helt ligegyldig om rækkefølgen er deterministisk, men selve operationen skal være atomisk.

Jeg skal selvfølgelig ikke nægte, at en overordentlig smart compiler kan finde ud af enten at lave den nødvendige lås eller at anvende en atomisk hardware operation; men jeg tror ikke på det. Koden til de to processer/tråde kan jo være skrevet helt uafhængigt af hinanden, og hvordan skulle compileren finde ud af det? De to progammører taler sammen og er enige om semantikken; men de bliver efter min bedste overbevisning begge nød til at fortælle compileren, hvordan den skal håndtere det. Og så er vi netop der, hvor en generel hardware abstaktion kommer til kort. Tag f.eks.

  1. ++(*p)
  2. ++(*q)

hvor programmøren ved at p er shared memory medens q er private memory. Hvordan skulle compileren finde ud af at det er nødvendigt at den første skal være atomisk med en passende hardware abstraktion, og den anden ikke behøver det?

24. juli 2020 kl. 11:54
C++ er svaret - men hvad var egentligt spørgsmålet?

Hej Jens

Det er næsten paradoksalt, at du bruger så meget plads på at beskrive, hvad det er compiler skal forstå omkring hardware, og samtidig generelt fortæller, at (sådan lidt groft sagt) programmøren ikke skal bekymre sig. Jeg har i stort set hele min professionelle karriere beskæftiget mig med software, der kører med mange parallele tråde og delt memory. Jeg har endda være med til at portere softwaren til nye platforme, og præcist mit eksempel med ++(*pp) har vi aldrig kunnet overlade helt til compileren. Det er slet ikke nok at skrive volatile (som vel reelt også ville være imod dit princip om at "compileren forstår det hele"), og hver ny hardware har sin nye implementering.

Og det er faktisk ikke blot nok at sikre at sådanne operationer bliver atomiske: Det skal også sikres, at såfremt en proces midt i denne operation skulle forsvinde (som i kill -9 hvis vi taler UNIX), at der stadig kan ryddes op. Den atomiske operation bruges jo typisk til at sikre at et objekt (åh nej, nu bruger jeg det ord, jeg selv er så arg modstander af) ikke modificeres, så den atomiske operation laver en lås eller mutex. Men hvis processen, der har låsen dør, så skal de resterende processer kunne rydde op alligevel. Og nu er vi vist helt sikkert derude, hvor compileren ikke har en jordisk chance for alene at forstå sammenhængen.

Når du skriver:

Den vil i princippet reservere hele lageret, hvis der ikke er styr på addresseområdet. I nogle tilfælde, kan vi analysere det, ved at behandle koden, og arbejde med mulige intervaller for alle variable.

kan vi så ikke blive enige om, at vi for længst er forbi det punkt, hvor det vil komme til at performe? Eller sagt på anden vis: Der kræves aktiv indsats fra programmøren, for at resultatet har den ønskede performance? Det er programmøren, der må fortælle compileren, hvilke objekter, der skal beskyttes af hvilken type mutex/lås, og hvornår der skal låses eller låses op. Måske kan compileren finde ud af det hvis dens opgave er at parallelisere en algoritme. Men hvis to programmører skriver hver deres kode som skal køre parallelt mod delt memory, vil compileren alene ikke have en chance, så i den situation er abstraktion af hardware utilstrækkeligt såfremt man også skal sikre performance.

I "gamle" dage, da alt ikke var Intel, var det meget forskelligt fra system til system. Noget hardware havde atomisk test-and-set, andet havde atomisk compare-and-swap, på nogle var det bytes, på andre words, og andre igen anvendte O/S interrupts til at lave user-space atomiske operationer. Jeg tror det vil være særdeles svært at lave som en one-size-fits-all hardware abstraktion, i hvert fald så længe den skal være så billig som mulig.

23. juli 2020 kl. 21:09
C++ er svaret - men hvad var egentligt spørgsmålet?

Jeg kan se på din kommentar, at det ikke fremgår tydeligt at jeg taler om hardware abstraktion.</p>
<p>Software abstraktion er også vigtigt - og som du nævner kan der være problemer, når der er mange lag af abstraktion. Dette er ikke et problem ved hardware abstraktion.

Jeg tror nu slet ikke vi er uenige, selvom jeg mere ser det hele fra software siden. Især er jeg absolut enig med dig i, at det skal være compileren, der genererer maskinkoden. Men når det er sagt, så er hardware jo meget andet end CPU; helt nær ved er der cache, lidt længere væk memory, måske numa, der er roterende og solid state diske, og der er netværk med meget variende latency. Hver af disse kunne - principielt - have sin egen hardware abstraktion med sin egen compiler feature. Hvis den ideelle compiler du beskriver, f.eks. kan lave kode, der eksempelvis automatisk finder ud af, at dit parallelle program ikke må læse og skrive samtidig til de samme bytes i memory, så ville det være fantastisk. Men mon det er muligt? Kan en compiler finde ud af, at to tråde, der begger laver

++(*p)

skal have det koordineret uden at programmøren på nogen måde fortæller om det og uden at det bliver dyrere, hvis den stump kode ikke kører samtidig i flere tråde?

Når vi så kommer til hele stakken, lige fra brugerens enhed, gennem adskillige lag af netværk, cpu og ram, for til slut at ramme noget ikke volatilt som en roterende disk, så er det at abstaktionen (indrømmet, især software) nemt giver problemer. Jeg mener reelt, at abstraktionen af software (med den stort set altid manglende beskrivelse af omkostningen) decideret forhindrer effektiv udnyttelse af resourcer, og det er uanset hvor smart compileren er i de mange lag. Det bliver aldrig til andet end lag, der ikke forstår de andre lag.

23. juli 2020 kl. 18:33
C++ er svaret - men hvad var egentligt spørgsmålet?

Abstaktion uden overhead er naturligvis godt, og det er naturligvis også godt, at sproget sikrer, at man ikke ved "håndkodning" havde kunnet skrive mere effektiv kode. Men der er alligevel en hage ved det, nemlig at abstraktionen meget ofte skjuler implementeringen fra brugeren.

Hvis alt jeg får at vide er, at her en en klasse med de-og-de metoder, så aner jeg ikke, om de metoder er dyre eller billige. Hvis jeg har en klasse, "bil", med en metode "farve", og jeg kun er interesseret i røde biler, så tjekker jeg om bil.farve()=='rød' uden at jeg har nogen som helst anelse om, hvordan dette er implementeret. Det er måske fint nok, at lave tjekket på en bil i minuttet, men er en per sekund ok? Tusind per sekund?

Jeg har gennem min lange karierre set utallige eksempler på dårlig performance, hvor det reelt har være et problem som dette, der var det underliggende problem. Abstraktionen gør, at der laves lag på lag på lag, så den samlede stak bliver prohibitivt stor, også selvom de enkelte lag er "abstraktion uden overhead".

23. juli 2020 kl. 16:03
»Idiotisk telefonsystem«: Derfor kan enhver stå bag SMS'en fra din mor eller chef

Lad mig lige supplere denne lødige diskussion med lidt humor: Jeg forsøger ind i mellem at trække "Computer Support" opkaldene ud ved at lægge telefonen på bordet og med passende mellemrum at sige noget som "can you repeat that, please", "left or right click?" eller bare "I see". Jeg tror jeg er kommet op på omkring 5 minutter før de indser at pranken er vendt om.

13. juni 2020 kl. 12:54
EU-generaladvokat: Forindstillede cookie-bokse tæller ikke som samtykke

Personligt er jeg ret ligeglad med cookies, og jeg vil prøve den nævnte "ja tak til det hele".

Hvad jeg finder langt mere irriterende er de næsten daglige pop-ups med "Vi vil gerne sende dig notifikationer". Nej tak, hold jer væk fra min opmærksomhed. Tak. Her er lovgivningen tilsyneladende bagud, men sådan vil det jo nok altid være: Hjemmesiderne vil hele tiden forsøge at suge information ud af hos eller proppe os med uimodståelige tilbud, og lige så snart et hul lukkes, åbnes et nyt.

28. marts 2019 kl. 15:23
Løsriv dig fra Googles fangarme - og bliv potentielt klogere

Jeg er kunde hos google, så mail, docs og kalender er helt fri for snagen og tilhørende reklamer. Det er ikke engang særlig dyrt, og de yder en rigtig god service med rigtige mennesker, man kan chatte eller tale med, når det er nødvendigt. Men maps og søgning er ikke en såkaldt "core sevice", så dem undgår jeg i videst mulig omgang. Osmand har bedre kort end google (i Danmark) og som andre også skriver er DuckDuckGo god til det meste. Jeg bruger næsten altid osmand som gps.

Jeg har forsøgt at blive 100% google fri, og man kan komme en del af vejen med Lineageos på Android devices. Der findes endda appstore med en række typiske utility apps, men man kan f.eks. hverken anvende Mobilepay eller Easypark uden Google play. Og så ender man med to telefoner, så en kører med og en uden Play. Så det er virkelig svært at blive 100% googlefri.

12. marts 2019 kl. 22:26
Peter Naurs datalogitanker er blevet uhyggeligt aktuelle

Det er en fremragende artikel; men jeg savner et aspekt, der kun netop berøres, nemlig hvordan vi lokkes af, at noget er "gratis". Hvis et måltid mad, en bil eller en jordomrejse er "gratis" vil stort set alle med det samme få tanken, at der nok er noget i vejen. Men sådan reagerer vi ikke på en gratis konto på et socialt medie eller en gratis søgemaskine.

Som de mange og forskelligartede dataskandaler de sidste år har vist, har udviklingen især været styret af, at vores naturlige skepsis overfor "gratis" er blevet sat ud af spil. Her må den store opgave, f.eks. i uddannelse være at genskabe den naturlige skepsis overfor at få noget forærende, idet man med en vis ret kan sige, at vores manglende forsvarsmekanisme mod "gratis" har gjort os selv medskyldige.

19. januar 2019 kl. 13:24