Ivan Skytte Jørgensen

Korrekt. Jeg forsimplede det. Direktivet er langt og kedeligt med juristiske spidsfindigheder. En bedre opsummering er måske: Retten til at stoppe irrelevante personlige informationer at blive videregivet til tredjepart.

bliver primært brugt af svindlere og kvaksalvere til at lave cover-ups

Retten til at blive glemt gælder ikke oplysninger som ikke er offentlige. Så medmindre i ligefrem publicerer alle jeres kundedata på jeres hjemmeside, så er der intet problem.

Så jeg forstår ikke din argumentation.

De eksempler du nævner lyder mere som om man er gået ud af en tangent, og f.eks droppet at opnå princippet om selvorganiserende teams.

Risikoen for rigiditet er ikke unikt for agile. Det kan også forekomme i andre tilgangsmåder (SA/SD, RUP, prototyping, vandfald, ...)

agile (med lille a) er ikke så svært: Bryd arbejdet op i mindre features og gør dem færdige en ad gangen. Acceptér at verdenen ændrer sig og kunden skifter mening. Sørg for automatiseret test så man kan rydde op i dårlige implementationer uden at ligge søvnløs om natten. Undgå vandtætte skodder mellem udviklerene. Acceptér at man ikke kan vide alt på forhånd. Altsammen gode ideer som (for det meste) hugget andre steder fra.

Der hvor filmen knækker er, når det bliver Church of Agile (med stort A). Pludselig bliver målet om at være fleksibel erstattet af øhm.. tja.. noget ridigt og meget lidt appetitelig. Men det er Agile! Og derfor godt!

Ovenstående skal nok få folk op af stolen. Men lad mig lige fortælle baggrunden for min erfaring: 15 år i virksomheden, med op- og nedture. Nogle personer hang stadig fast i at gerne ville skrive store specifikationer, men kunne presses til at splitte features op. Nogle ville gerne have mere kundekontakt, men kunne ikke presses til konsulent/on-site support. Jeg var sendt ud til kunder flere gange og arbejde generelt tæt sammen med supportafdelingen. Jeg tog også vande-potteplanter-tjansen, for så kom jeg forbi alle kollegerne mindst en gang om ugen. Efter en længere række frasalg/tilkøb/fusioner blev afdelingen købt af en større virksomhed. De sendte en præst fra Church of Agile uden jordforbindelse. Selvfølgelig skulle alle kunne kode alt. Selvfølgelig var hjemmearbejde ikke muligt for så kunne man ikke være med til daglig standup. Ingen personlig ansvarsområder (men der kunne allernådigst være "subject matter experts"). Selvfølgelig skulle der omplaceres 2-3 udviklere til at være product owners (som skulle bruge omkring 120% af tiden på møder), men nej, der kunne ikke skaffes flere hænder. Jeg tog en dyb indånding og indleverede min opsigelse. I modsætning til det man normalt siger "people join companies but leaves managers", så forlod jeg ikke pga. min chef (som faktisk var smadderdygtig - han kunne bare ikke skærme imod det ovenfra kommende pres).

Så: 1: lær fra agile. Der er masser af gode ting i det. Målet er at kunne skifte retning hurtigt. 2: Agile (med stort A) skal dø

Emnet behandles faktisk, men dit argument holder ikke. Ved begge nævnte angrebsvektorer, vil angriberen have adgang fra dag 1 og X dage frem. Data er kompromitterede og der er andre forsvarsmekanismer som må træde til, f.eks. logning af anomaliteter i miljø, dataadgange og logins.

Dertil er periodisk passwordskifte ikke til for at eliminere det, du antager, nemlig shouldersurfing og keyloggere. Derimod er kravet til og skal måles op imod aktuelle cracking-hastigheder, såfremt krypterede repræsentationer kompromitteres.

Det, som jeg savner, er et mere modigt og fornuftigt skridt: beløn brugere for gode passwords med længere levetid. F.eks. "Du har valgt passwordet '43HalfGiraffes', som med offline brute-force vil tage circa 40 århundreder at finde, så levetiden er sat til 1% af det, dvs. 40 år. Tak for at vælge et godt password og hav en god dag."

Bloggen skøjter let og elefant henover den problemet med periodiske påtvunge passwordskift. Periodisk udskiftning skal beskytte mod, tja, hvad? At nogen aflurer passwordet med øjne eller keylogger. Nå. Der hvor filmen knækker, er antagelsen at den person så pænt venter 3 måneder med at udnytte det. Den antagelse mener jeg ikke holder.

Så snart passwordet er opsnappet,så må man forvente at det bliver udnyttet indenfor et par dage, og patientjournalerne er lækket, bankkontoen tømt, forretningsstrategien sendt til konkurrenterne, og hjemmesiden ændret til en Bieber fan-side. Med et påtvunget skift hver 30. dag så vil en angriber have gennemsnitlig 15 dage at udnytte det i.

For den paranoide er den eneste logiske løsning på dette at kræve passwords udskiftet hver dag. Eller sågar hver gang man logger ind. Og det gælder alle brugere!

Den mere realistiske ville overveje:

• ingen periodisk tvungne skift
• midlertidigt unikt password når man er ude i byen / i untrusted miljøer. Så er der en chance for at brugere vil vælge fornuftige passwords og holde dem sikre. Den eneste ulempe er, at den sikkerhedsansvarlige vil blive ked af det, fordi han ikke længere kan brugere til at danse efter hans pibe og skifte password hver 30.dag.

Der er selvfølgelig andre fornuftige ting man bør overveje i delområder: brugerrettigheder begrænset til det der er behov for, uddannelse af brugere, fysisk sikkerhed, two-factor authentication, ...

Jeg kan komme på to kreative ideer i gasmåleren: 1: Gør batteriet bruger-udskiftelig. Intet batteri = ingen gas. 2: Indsæt en lille turbine eller rokke/vippe-ting i gasrøret, og brug til at generere elektricitet til at oplade batteriet (eller blot en kondensator). Der er eksempler på lavenergi-dimser som kan gøre nyttigt arbejde, f.eks. et videokamera som hev energi ud af termiske forskel mellem rumtemperatur og væggen og kunne sende et 256x256 pixel sort/hvid billede et par gange i døgnet.

Men ja, med batterier skal der hugges en hæl og klippes en tå. Jeg sidder med zigbee-pro dimser, tja.. når de skal have et CR2032-batteri til at holde i 5 år, så kan der ikke frådses.

Dengang jeg var dreng skulle vi skifte bits op ad bakke - begge veje.

Jeg er glad for at jeg ikke længere er nødt til i hvert tilfælde tælle bits og clockcykler, men i stedet for det meste kan arbejde med højere abstraktioner, klaske ting sammen i scriptingsprog som performer "godt nok".

Men jeg er også glad for at have været med fra næsten starten, og når det er nødvendigt, kunne gå ned på bits, clockcykler, eller sågar blot ikke-cloud-løsninger.

Tjo, det er heller ikke noget stort problem. Det eneste sockets og filer i praksis har til fælles er close(), read() og write(). Man kunne så overveje om de i det hele taget begge skulle bruge samme namespace (descriptors), men jeg har arbejdet med OS/2 hvor file handles og socket descriptors ikke var fælles, og det var heller ikke ideelt. Eller i den anden ende af skalaen: win32, hvor filer, mutexes, sockets, ...altsammen er handles, som dog ikke opfører sig helt ens.

File descriptors abstraherer væk fra om noget er en fil, pipe, socket, en rå disk, osv. Og abstraktionen fungerer rimeligt, men den lækker aligevel nogle steder:

• man kan ikke lave select() på en fil Hvorfor må jeg ikke lave select(...read) på en fil for at vågne når nogen har appendet til den?
• sendfile() skal have en fil som source-descriptor. Og der findes ingen recvfile() API.Hvorfor det? Det ville da ellers være fikst hvis det var et API til at kopiere x bytes mellemto descriptors
• TCP OOB data kan forekomme på TCP socket descriptors.

Det er ikke noget stort problem, men dog aligevel et irritationsmoment.

Det kunne være interessant at høre hvad du mener om DeMarco/Lister bogen "Waltzing with Bears".

Bare vent til du kommer til comes-from og multithreading. Det er så smukt at ikke et øje er tørt.

Målet med INTERCAL er bl.a. at kun have features som ingen andre sprog har (og ingen ønsker at have). Det har betydet at sproget er blevet mindre gennem mange år :-)

Jeg overvejede at foreslå følgende feature til INTERCAL newsgroup:

DO
  ...kode...
UNLESS ...betingelse...

Det er nyttigt at studere tåbelige, farlige og forældede features i andre sprog (INTERCALs ABSTAIN og COMESFROM statements, COBOLs "ALTER" statement, Smalltalks mulighed for at omdefinere hvordan addition virker på heltal, osv.), fordi man så i sit daglige arbejde indser faren når man er ved at skrive ævivalenten til ALTER i f.eks. C++

Det er relevant at der er faldet dom sidste år i en relateret sag:http://www.domstol.dk/aarhus/nyheder/domsresumeer/Pages/StraffenbortfaldtisagmodAarhusHavnog2ledelsesrepr%C3%A6sentanterfraAarhusHavn.aspxEller DRs mere læsevenlige men deltaljefattige version: https://www.dr.dk/nyheder/regionale/oestjylland/dom-ulovligt-laese-medarbejdernes-sms-beskeder

Det korte af den lange er at hvis en medarbejder kan forvente at kommunikationen ikke overvåges, men arbejdsgiveren så snuser i trafik/sms/...,så vil arbejdsgiveren få nærkontakt med straffelovens §263

Telefonens position skulle dog være lovlig at spore, da der ikke er private beskeder i det som sådan, og jeg erindrer at der tidligere er faldt dom for at det var lovligt for et transportfirma at spore lastbiler, og påtale når chaufføren parkerede i et røde-lygter-kvarter i Italien i stedet for at levere varer.

youtube-kanalen computerphile har en glimrende video, som belyser farerne ved en generel AI: https://youtu.be/tcdVC4e6EV4Der påpeges at for at lave en generel intelligens så skal den have en intern model af verden, så den kan beregne konsekvenserne af handlinger, og vælge den bedste handling for at optimere dens fastsatte mål.

Hvis vi tager bil-analogien (hurra!), så kan man jo sætte sig ind i en intelligent bil og blot fortælle at man skal på arbejde i X-købing, og bilen vil så sørge for at man kommer så hurtigt frem som muligt. Men vi vil godt have den til at være smartere, så den véd at der er Roskilde Dyreskue og på det tidspunkt at bilen når til Roskilde vil der være massiv kø, så det er hurgtigere at tage landevejen. Eller at der er vejarbejde eller sne, og lige i dag er det hurtigst at tage toget.

Men lige så snart man bygger en en fleksibel model af verdenen ind i en AI, så vil den begynde at kunne manipulere den rigtige verden, f.eks. ved at sende emails til trafikministeren med forslag om at hæve fartgrænserne. Eller SMSer til andre trafikanter at der er vejarbejde på motorvejen og de bør tage landevejen. Og vupti - frie kørebaner på motorvejen. Men også at den snakker med de andre intelligente biler og timer indkørsel/afkørsel/hastighed så trafikken flyder optimalt og alle kommer hurtigst frem.

Videoens pointe (som jeg er overvejende enig med) er, at når en AI har en intern model af verdenen, som tilpassses observationer, og AIen kan lave optimum-søgninger, så vil den begynde at lave ting, som ingen kan forudsige.

Hvis budgettet er 200 millioner USD, så bør det ikke være svært at udvikle et skræddersyet alternativ eller sponsorere en opgradering af eksempelvis PostgreSQL, så at den kan løse din opgave.

Hvis man har 200 millioner i budget så er det nok et forretningskritisk system. Muligheder: A: lav en skræddersyet DB Med den track-record SW udvikling har: Sandsynlighed for at det vil virke: <100%. Sandsynlighed for at det er klar til når man skal bruge det: <100% B: Brug en veletableret og gennemprøvet RDBMS. Sandsynlighed for at det vil virke: >80%. Sandsynlighed for at det er klar til når man skal bruge det: 100%

Og så laver man en risikoanalyse og sammenholder hvad den skræddersyede DB vil koste sammenlignet med oracle/ms/ibm licens. Nogle gange er A bedst, andre gange er B bedst.

Hvorfor er det man vælger at blive ved med at bruge Oracle DB ud over at man har nogle eksisterende systemer der bruger det?

• hårde grænser er ret høje (f.eks. max indexes pr table: unlimited; max partitions per table 1048575, max SGA (memory): 16 exabyte, osv)
• der er mange ting som kan tunes
• at den skalerer i praksis (så ja, man kan forvente at den faktisk kan udnytte ens flotte nye Sun M7-16 med 512 cores og 16TB ram, eller HP Superdome med 128 cores og 4TB ram)
• at der er et utal af add-ons, kompatible produkter, konsulenter, supportere, osv.

Men det ville være synd at sige at den er billig, eller nem at danse med.

Note: Der findes Oracle Database 11g Express Edition, som er gratis, dog begrænset til 11GB data og 1 CPU.

Hvad er egentlig grunden til at man ikke kører dual stack på mobil netværk?

MSISDN telefonnummer) og IMSI (simkort-nummer) ligger på sim-kortet. IMEI (hardwarenummer) ligger på telefonen.

Så for at undgå sporing kræver det at man smiderr både telefon+simkort ud.