Per Dalgas Jakobsen

Danske forskere skal undersøge muligheden for blockchain-valgsystem i Grønland

Min første tanke da jeg så denne artikkel var: "Det da løwn" - KU8

Det næste var: "Almost anything in software can be implemented, sold, and even used given enough determination. There is nothing a mere scientist can say that will stand against the flood of a hundred million dollars. But there is one quality that cannot be purchased in this way — and that is reliability. The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay." - C.A.R. Hoare

Det er for så vidt fint at nogle forsker i det (uafhængig forskning vel at mærke), selvom jeg har svært ved at se hvordan man sikrer mod valgpression, hvad enten det er fra ægtefællen, arbejdsgiveren eller fagforeningsbossen(?).

120 mill. kr. for et folketingsvalg hvert 3.-4. år, og vel det tilsvarende til kommunalvalg, altså i omegnen af 10 kr. per dansker per år (er det ikke værre end det?)

"Håbløst forældet" - Ja tak herfra, også selvom e-valg kunne betyde at vi kunne slippe af med en god portion af alle politikkere; Hvis vi kan stemme så nemt, har vi vel ikke brug for nogen til at repræsentere os...

Hvem skulle forresten i givet fald specificere og realisere sådan et system? The usual suspects??? - What could possibly go wrong o_O

21. oktober kl. 20:31
Microsoft-chef: Stop nye projekter med C og C++ og brug Rust i stedet

I min optik har C og C++ været outdated i mange år - Jeg betragter dem faktisk som stenalderværktøjer. Jeg har kodet i begge sprog i et par årtier, og selvom jeg har tillært mig mange idiomer for at imødegå mangler i sprogene, har jeg aldrig lært at sætte rigtig pris på dem - Det er simpelthen for nemt at lave fejl i dem.

Jeg holdt for nogle år siden et lille foredrag om Ada, hvor een af tilhørerne der kendte til Rust, sagde noget i retning af: "Hvis Ada har eksisteret i så mange år, og kan bla. bla. bla., jamen, hvorfor så overhovedet Rust?!?" Ud fra det ganske lidt jeg har hørt om Rust, så tænker jeg at de største forskelle er alder (modenhed), navn og syntaks. Jeg foretrækker Ada, men hvis Rust er det brækjern der skal til for at redde verden fra C og C++, så står jeg helt sikkert på sidelinjen og hepper på Rust!

Jeg har hørt utallige undskyldninger for at C/C++ er bedre end (name-your-language), men den eneste jeg kan se er: "at de er mest udbredte".

Jeg tror i øvrigt det mindste produkt jeg har lavet i Ada på AVR var på ~1.5kB flash-kode og ~30 bytes RAM. Arbejder dog normalt på mellemstor kodebase på ~1MSLOC Ada (ikke på AVR :o)).

29. september kl. 09:32
IT og strømforbruget

Jeg bruger forøvrigt en Voltcraft Energy Logger 4000, der logger tid, spænding, strøm og power-factor hvert minut. Overfører data via et SD-kort og jeg bruger https://github.com/Lekensteyn/el4000.git (python-script) til at tække data ud af deres binære format. Fungerer faktisk ok (bruger angiveligt selv 1.5W ;-))

20. september kl. 09:20
IT og strømforbruget

11 WATT !!!!

Min nu deltidspensionerede ~15 år gamle server, der har påtaget sig backup-tjansen, kan ligge og sove, lyttende på wakeonlan eller vågne når klokken bliver mange, med et standbyforbrug på 0.7W.

Men vores forholdsvis moderne (<3år) massagestol bruger 11W i standby på at holde øje med om nogen mon kunne finde på at trykke på tænd-knappen!!!

11 WATT !!!!

Nå, men jeg må videre rundt i huset med min sur-gammel-mand-katalysator (aka. elmåler)...

19. september kl. 22:31
Er der noget godt at sige om cryptocurrency ?

Anders Rosendal skrev: Du var selv i retten. Fordi Lenovo ikke ville overholde dansk lovgivning. Hvordan gik det? Føler du systemet fungerede efter hensigten?

Som jeg husker retssagen, fungerede systemet fejlfrit. Hvad er pointen?

16. maj kl. 16:04
Kære Rejsekort(et)...

Der er nok mange ting ved Rejsekortet der kunne laves om, måske endda bedre, men den største fejl mener jeg ligger i den manglende kvittering til den rejsende.

Mit bevis for at have indløst en billet? Centralt i Rejsekortets eget system, jeg kan blot håbe...

Min sikkerhed for at billetten kun er betalt til destinationen? Centralt i Rejsekortets eget system, jeg kan blot håbe...

Jeg ville være væsentlig mere tryg ved systemet om jeg havde en kvittering for at have checket ind når jeg checkede ind, og en kvittering for at have checket ud, når jeg checkede ud. Kvitteringen må for så vidt gerne eksistere på min telefon...

20. september 2021 kl. 22:51
Kære Rejsekort(et)...

Har lige fået en tilsvarende mail, check-in 05-09-2021 kl 17:37 (check-ud ca. 30 min. senere). Er sikker på at den blev checket ud, men computeren har jo altid ret...

Gad vide om der har været uforholdsvis mange "manglende check-ud" deromkring? Kunne også være interessant at vide om der har været andre check-ud på standeren i et tidsrum deromkring...

17. september 2021 kl. 18:12
XGS-PON - en tresporet motorvej i din forhave

Ja, fotografer og andre med stort burst-behov kunne godt være en use case.

Ja, i 2010 kunne det have været rart at have haft her[1]. Selvom man godt kan få 6GB ind på et døgn på 2.5Mbit/s, valgte vi alligevel en variant af Tanenbaums "Never underestimate a ...".

Umiddelbart var der nok bedre salg i et produkt med decimeret latency ;-)

Lige nu har jeg selv svært ved at se hvad jeg skulle bruge 2.5Gbit/s til, men på den anden side sagde nogen engang: "There is no reason anyone would want a computer in their home." - Det er nok mest et spørgsmål om hvor lang tid der går, før 2.5Gbit/s er standard...

[1] hører stedet under Nordenergi, TDC, eller? ;-)

30. marts 2021 kl. 08:54
Der hvor vi skal hen bruger man ikke byte-alignment...

jeg er ikke engang sikker på om ADA blev brugt af andre NATO lande, det skulle vist være ret fantastisk sprog af det jeg har hørt - på den anden side så er kirkegården med afdøde programmeringssprog fyldt af fantastiske sprog som aldrig nåede WinTel og derfor uddøde.

Sproget skrives: Ada (et navn efter Lady Ada Lovelace, ikke en forkortelse).

Sproget er ikke uddødt: men der er bestemt alt for få der bruger det og endnu færre der reklamerer med at de gør det. Det er f.eks. nok ikke så kendt at NVIDIA er ved at porte fra C til Ada/SPARK for nogle af deres produkter.

Ja, det er et fantastisk general purpose sprog.

Og R1000'eren er et fantastisk IDE. Tre hurtige om IDE'et:

  • Kodesnipets i den kontekst-sensitive hjælp kan selvfølgelig eksekveres in-place.

  • Har man behov for at prøve et metode-kald, gør man det bare - Kommandolinjen er "ikke andet" end direkte eksekvering af Ada-snippets.

  • Code-completion er ikke bare en one-step-at-a-time, f.eks. kunne indtastningen "c.d.v(m);" efter tryk på "complete"-knappen blive til "Container.Decode.Visit (My_Visitor);" (forudsat ingen tvetydigheder findes). Endnu et sted hvor Ada's stærke typer kommer til sin ret: det gør det nemmere at indsnævre hvilke parametre der kan være tale om.

Og det er 30 år siden man kunne det...

21. december 2020 kl. 23:23
Let's Twist again...

Da jeg anskaffede en 3D printer, havde jeg alle mulige visioner om egne kreationer, opfindelser, m.v. I dag nogle år efter må jeg sige at, vel har jeg lavet mange kreationer på den printer, men jeg havde ikke forestillet mig hvor mange reservedele jeg kom til at lave; reservedele til ting der ellers var røget til storskrald eller småt brændbart.

Jeg kunne godt ønske at 3D-filerne til disse reservedele lå tilgængelig (open design?), men måske er det mere realistisk bare at "printe" en 3D skanner til det formål :)

Som ethvert værktøj skal man (lære at) kende dens begrænsninger og styrker. 3D printeren kan f.eks. "fylde" materialet med lufthuller, så vægten af det færdige emne kan blive væsentlig lavere (eller højere[1]) end hvad der ellers ville have været muligt med samme materiale.

Dejligt at det på den måde også lykkedes at holde Facit'en i form! R1000-400 maskinen blev faktisk også udsat for et par print [2][3]!

Velbekomme PHK :-)

[1] Printeren pauses undervejs og hulrummene fyldes med et tungere materiale.

[2] Nye isoleringsrør til R1000'erens PSU.

[3] Et monteringsbeslag til R1000'erens SCSI2SD (ikke en reservedel).

23. august 2020 kl. 10:35
Datamuseum.dk: Vi har et problem...

Jamen, vi har jo endnu ikke fået beskrevet, endsige fuldt forstået, den Rational 1000-400.

Vi skal da ha' beskrevet og formidlet om det +30 år gammel software-udviklingsmiljø der ikke står tilbage for selv de nyeste, og på nogle punkter stadig er foran (hvilke andre udviklingsmiljøer kender vi hvor man f.eks. kan single-steppe baglæns - Ting som kontekst-sensitiv hjælp, team-collaboration, project management, versionskontrol, integreret cross-compiling, continuous deployment, m.m. er jo en selvfølge).

250 bananer sendt afsted herfra!

3. august 2020 kl. 01:04
Linus: Overbevist om at vi får andre sprog i kernen

Kan du give et par eksempler på C-kode, som er implementationsafhængig af compileren?

Du laver sjov, ikk'?!? Men ok, jeg leger med:

Hvad er resultatet af følgende, med din compiler? Hvad burde resultatet være i henhold til standarden?

  1. #include <stdio.h>
  2.  
  3. void main (void)
  4. {
  5. short int a = 65535;
  6. short int b = a >> 1;
  7. printf ("%d, %d\n", a, b);
  8. }

Tag gerne http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf og søg på "implementation-defined".

16. juli 2020 kl. 16:57
Linus: Overbevist om at vi får andre sprog i kernen

Pascal og Ada påbyder, at det checkes, om et tal, der gemmes i en variabel, ligger i det angivne interval. Det sker som regel på køretid, hvilket nok ikke egner sig til kerneprogrammering.

Compilerne er efterhånden så gode at forbavsende mange tjeks sker compile-time. Input "udefra" skal tjekkes (men det bør man jo gøre under alle omstændigheder). Bruger man SPARK Silver level er de tjeks forøvrigt helt unødvendige, for så har du bevist at du har tjekket hvad der bør tjekkes.

Når man nu (så let) har mulighed for at bevise fraværet af run-time exception, bør Kerneprogrammering selvfølgelig inkludere dette.

6. juli 2020 kl. 14:18
Linus: Overbevist om at vi får andre sprog i kernen

Jeg ville ønske at Ada/SPARK fik en langt større udbredelse end det har i dag. Typesikkerhed der virker, tasking som en integreret del af sproget, distribueret processering, veldefineret opførsel, fin interfacing med sprog som C, verifikation, etc... - At vedligeholde og forbedre et +1MSLOC system er faktisk til at håndtere! Største anke mod Ada er som regel udbredelsen. Hvis det blev introduceret i Linux kernen, ville dette givetvis ændre sig.

Man har vel lov at håbe :-)

2. juli 2020 kl. 19:54
Hvor svært kan dét være?! (960/N)

Ja, en "Documation 200" hulkort-scanner som nogen gange virker og nogen gange ikke virker :-)

Til dette formålet er jeg kun interesseret i auto-feed: tag kort, kør frem, hold stille(?), (trig kamera med baglys, trig kamera med forlys), næste...

Hvad er naturen af "ikke virker" - mekanisk, kortlæsning, ...? Kan den overtales til at køre rent mekanisk? - Jeg kan se at den kan sættes i "Remote"...

Der er den fodnote at det rent bevaringsmæssigt kan give mening at scanne hulkortene og (bit-)arkivere billederne.

Tanken var at tage billeder af den ene side (forside eller bagside), sammen med hul-placeringer.

18. juni 2020 kl. 12:46
Hvor svært kan dét være?! (960/N)

Nogle biblioteker har Xerox-maskiner, der kan skanne til lagring - med arkføder.

Med bagbelysning? Hvilket bibliotek? Hvorfor må jeg ikke lege med LEGO?

17. juni 2020 kl. 20:14
Hvor svært kan dét være?! (960/N)

12919 hulkort.

Hvis jeg kunne få lov at slippe for at lægge dem på en lysplade een for een, så ... Har vi (DDHF) en dims der kan føre en bunke af kort forbi et sted hvor vi kan lægge noget lys ind bagved, samt et kamera foran?

Man får jo næsten lyst til at lave en LEGO Mindstorms løsning til at tage et kort frem ad gangen og føre der henover et på lyssensorer (med baglys). Hvis den bare kunne være stabil for 2.5km hulkort...

17. juni 2020 kl. 19:18
Svære valg

"... kunne man klare den med kommunal ladvogn fyldt med stemmeurner der kørte rundt med en "hjem-is-klokke" og samlede stemmekuverterne sammen."

Nyvasket skraldebil med 2 valgtilforordnede bagpå :)

12. juni 2020 kl. 21:39
Et centralt spørgsmål: Skal vi rydde op i it-systemet eller udvikle et nyt?

Som yngre, havde jeg næsten altid den holdning at var noget skrammel, og burde skiftes helt ud. Nu tager jeg det som en udfordring: "hvis jeg kan forestå at rette op på , så kan jeg alt" :-)

Erkendelser: Jeg kunne ikke på egen hånd lave et nyt system med dokumentation, plus alt det andet der følger med. Det gamle system holder faktisk noget i drift i dag, omend med en del support og meget besværlige udvikling.

Hvad så?:

  1. Find ud af hvor kodekvaliten skal forbedres: Kodestil, dubleret kode, cyklomatisk kompleksitet, coverage, etc. Og mål den eksisterende kode. Lav commit-hooks så ændrede kode-filer ikke accepteres hvis de har dårligere metrikker (op til et vist niveau). Start tidsserier med metrikkerne så man senere kan se og henvise til effekten.

  2. Etablér infrastruktur til automatiserede tests. - Det skal være nemt for de andre at begynde at lave tests. Og teamet skal hjælpes til at huske at lave tests, f.eks. ved at hjælpe dem til at få startet på deres næste supportsag.

  3. Ret kun i kode, hvorpå der er en support-sag (så er der nogen til at betale for rettelserne).

  4. Er der nogle gennemgående problemer med den eksisterende kode, så lav softwaremønstre til at løse de pågældende problemer, og stil dem til rådighed for dem der får fat i problematisk kode, så de ved hvordan den type problemer skal løses. Start f.eks. med den type problemer der er flest supportsager på.

Og så ellers bare igang med at vedligeholde, vejlede, forbedre, og jævnligt forbedre selve processen. Et +30 år +1MSLOC system tog under to år at forbedre fra "håbløst" til "ikke så tosset endda".

Tanken om den "ideelle arkitektur" kan man jo passende bruge som guide for de ændringer man planlægger.

Bare det at teamet kan mærke at systemet løbende bliver bedre, giver ekstra motivation, energi og ikke mindst arbejdsglæde.

18. juni 2019 kl. 09:16