For mig at se handler diskussionen (og i hvert fald mit indlæg) ikke så meget om hvorvidt fuldt selvkørende biler er klar om 1, 5 eller 100 år, eller om de er en god ting. Det må bero på en faglig vurdering blandt folk der arbejder med det, og det er ikke det Miguel taler om. Miguel's påstand er tilsyneladende, at folk lige nu tror selvkørende biler er her og fungerer, fordi de er besat af en AI religion (genlæs evt. præcis hvad der står i artiklen om de selvkørende biler). Det har jeg ikke mødt nogen der tror (bevares der er da sikkert enkelte i verden der gør det, men det retfærdiggør næppe Miguels problematiseren). De eneste jeg har hørt påstå selvkørende biler er om hjørnet er bilfabrikanterne, og det er jo sædvanlig marketing.
Men at - som Miguel gør - sige at "en selvkørende bil er jo blot nogle kameraer og neutrale netværk og det er jo bare statistik" bibringer ikke meget til diskussionen. Mennesker kører fint (det meste af tiden) baseret på netop 'kameraer' og neutrale netværk. Og bilerne bliver trods alt mere og mere selvkørende via disse teknologier. Der er således for mig at se intet naivt og blåøjet i at tro det på et tidspunkt kan løses af den vej, men vi er der tydeligvis ikke endnu. Men det der skiller er at Miguel påstår at mange tror vi er der nu - men hvor er dokumentationen?
Jeg møder heller ikke folk der tror AI er religion og magisk eller som tror at Smittestop-app'en kan løse alle problemer. Ligesom jeg heller ikke tror de folk i staten (Sundhedsministeret etc.) der arbejder med app'en er nogle gemene kodekarle der tror at alt kan løses med en app, uden tanke på den sociale kontekst.
Det hele er Miguels stråmænd fra ende til anden. Hvis jeg skulle kunne tage det seriøst, skulle der være præcise referencer til hvor en sådan er religiøs dyrkelse gør sig gældende og/eller har negative konsekvenser i samfundet, så det ikke bare er nogle lidt diffuse la-la påstande.
Intet i verden er nemmere end at være bagklog eller at argumentere imod stråmænd.
Jeg skal være den første til at kritisere AI hype. Men jeg synes måske diagnosen her er forkert, og det bliver fremført på en "alle andre er idioter undtagen mig", selvom de faktisk pointer er ganske trivielle.
Jeg tror ikke folk (langt de fleste) grundlæggende er så dumme eller har misforstået AI i en sådan grad som Sicart foregiver. Det største problem indenfor AI er at snarere sælgerne/firmaerne der 'oversælger' de faktiske capabilities og hvor langt de er. Tag f.eks. Tesla, Google etc. der for mange år siden hævdede at de om 1-2 år havde selvkørende biler. Det er tydeligvis ikke tilfældet. Men dermed kan det ikke konkluderes dette er en umulig opgave. Det ligger bare længere ude i fremtiden. Men det er et marketings/ærlighedsproblem, som kendes i mange brancher - ikke et grundlæggende problem med folks IT-forståelse eller at folk er dumme og naive.
Jeg synes der generelt er lidt mange stråmænd inde over her også.
F.eks. smittestop-app'en som nævnes som eksempel. Det nævnes som om alle havde regnet med den ville løse alle problemer også kan man komme med noget akademisk højpandet herre jemini "Åhhh tænk hvor naive de var, at de troede man kunne løse det her komplicerede samfundsproblem med en app. Åh jeg må le!". Men var der nogen der troede eller sagde Smittestop kunne løse alle problemer? Er det korrekt at der ikke blev lavet analyser af app'ens konsekvens hvor også praktiske og sociale faktorer blev inddraget? Blev det netop ikke hele tiden fremført som blot ét ud af mange redskaber der kunne nedbringe kontakttallet (så det kommer under 1). Selv hvis det nedbragte kontakttallet med 0,1 har det jo også ret - hvis masker giver lidt, hvis håndvask giver lidt. Det kan godt være Smittestop samlet set ikke havde den store effekt (er der dokumentation herfor?) men det er ikke det samme som at sige, at det at man prøvede, var udtryk for en naiv hoved-under-armen tilgang, som Sicart antyder. Virkeligheden er kompliceret og selvom man er fuldt bevidst om det, må man jo komme med sit bedste bud.
Mht. at kunstig intelligens er en statistik beregning der munder ud i et tal - jeg er enig. Men hvem siger en hjerne ikke også er det? Dermed siger denne ganske naive observation ikke meget om de capabilities vi kan forvente af kunstig intelligens. Og der er jo hele tiden eksempler på at systemer med kunstig intelligens der løser problemer der var helt utilgængelige for IT tidligere. Der er lang vej igen, og som altid vil ting blive oversolgt.
Jeg er enig i privacy-bekymringen. Ja, lidt tilfældig støj adderet gør det sværere, men ikke umuligt. Problemet er at informationen stadigvæk er tilstede selvom man adderer tilfældig støj. Det er bedre, som Povl foreslår, helt at fjerne informationen via afrunding (d.v.s. i praksis at dele kortet ind i kvadranter af en eller anden størrelse), for så er informationen væk. Man skal så sætte en tærskel for graden af afrunding.
Men det bringer mig til en anden ting nemlig hvad behovet er. Den enkelte kunde kan have behov for at se status på sin egen forbindelse. Derudover har kunden ikke et behov for at se status på enkeltforbindelser, men mere bare overordnet status for området. Så her kunne man kollapse alle tilsluttet samme central (eller anden relevant delt infrastruktur) ind i én prik der så evt. via farve eller tal viser status. Hvis det ikke er muligt at bestemme denne inddeling, kan man også bare lave inddelingen ud fra de ovennævnte celler (som opstår ved afrunding) og så indenfor hver celle skrive det overordnede resultat for det område. En sådan celle kunne være fx 2x2 km. Man kunne vel også variere cellestørrelsen ud fra antallet af abonnenter.
Hej PHK,
tillykke med der gik 11 år første hul. Og fin håndtering!
Jeg er gammel C programmør men må tilstå jeg ikke ved hvad "inline-C" er jf. den side du linker til. Jeg kender selvfølgelig godt "inline" keywordet (selvom jeg yderst sjældent har brugt det) som hint til compileren om inlining af en funktion, men tænker det næppe kan være det du henviser til. Jeg ved heller ikke hvad VMOD er. Jeg har læst Kernighan's kommentar ang. manglende escape i Pascal, og det ser ud til at være en kritik af manglen på type coercion i Pascal. Men type coercion må man jo sige findes i standard C. :) Er inline C en særlig konvention eller måde at bruge C på?
Det er præcis pointen. Dertil er overskriften misvisende. Mere korrekt var "Google kunder kan nu selv vælge nøglen som Google bruger til at kryptere deres data". Der er en stor forskel!
Det er jo fint nok man selv kan generere den. Men det giver i hvert fald ikke noget i forhold til hvis man generelt har mistillid til Google (eller mistænker de er aflyttet af NSA), eller hvis man ønsker kontrol over egne data, for de får jo netop kendskab til nøglen! Det giver kun noget hvis man specifikt har mistillid til genereringen af nøglen hos Google, og ønsker at generere den selv - men samtidigt har fuld tillid til at de kan opbevare og bruge den sikkert.
Den eneste sikre måde er at kryptere data inden de uploades til clouden. Det fungerer for storage men selvfølgelig ikke for mere komplekse services hvor cloud-changen rent faktisk skal kunne se data i klartekst.
Kan virkelig ikke se det innovative eller fintech agtige i det. Det er vel også bare dem selv der kalder sig det, og så skriver pressen af!
Allerede i starten af 00'erne kom der rene "internetbanker" hvor det innovative var der ikke var en fysisk bank og rådgiver osv. men derimod en webbank der kunne det meste og som typisk havde lavere gebyrer og bedre vilkår iøvrigt. Se DET var innovativt. I det her tilfælde slår de på at de er en REN mobilbank. Men hvad er forskellen - et spørgsmål om hvorvidt klient-side koden kører i JavaScript/HTML i en browser, eller som "appkode" i operativsystemet. En i denne sammenhæng ligegyldig teknisk detalje. Det kan umuligt være det der er det innovative. Især når nærmest alle banker i forvejen har en app og har haft det i årevis (ellers havde der måske været noget at komme efter).
Dertil kommer at de ikke engang er deres egen bank, men bruger en eksisterende banks backend, systemer og banklicens! Med andre ord er der tale om ren front-end.
Med andre ord, Lunar Way har alt bagagen fra før (gammel tung (perceptionmæssigt) backend og tilhørende omkostninger) og et mikroskopisk subset af funktionerne, og tilgengæld ingen nye funktioner, services eller innovationer.
Det eneste man kunne sige der er tilbage af nyskabelse kunne være "begrænsningens kunst" som ligger i at have en simpel app. Det er nok derfor de praler med der er så få funktioner der er åh så nemme. Jeg har dog aldrig hørt om folk der har haft svært ved at bruge funktionerne i deres alm. webbank app og da slet ikke de simple funktioner som er det eneste denne bank undersøger.
Tror ikke jeg bare er gammeldags - så da i hvert fald potentialet i Facebook straks det kom. For selvom der var analogier til andre platforme var der da nye muligheder her samt en anden type community, som jo må siges at være en vigtig differentierede faktor for et socialt medie! I modsætning til bankforretninger, i hvert fald den type vi taler om her, som er væsentligt mere sammenlignelige.
Jeg tror også hele "forretnings"idéen er at blive købt. Hvis de bliver det, bliver det af en bank med tungnem ledelse som blot har hørt "fintech, fintech, fintech" på tilpas mange konferencer og tænker at "shit det skal vi med på - vi køber op! Hvor var det nu jeg læste om de her unge og innovative der var i gang med at distrupe det hele. Nå ja, Lunar Way hed de. KØB FOR HELVEDE".
Har ikke arbejdet med EMS i C (men har i assembler, men går ud fra man kunne få en pointer til EMS vindues-bufferen, og der var et API der kunne bruges til at ændre hvad vinduet skal pege på det større EMS-lager. Og ja, med frem/tilbage funktioner vil det give mulighed for ubegrænset hukommelse (svarende til Turing-maskinens køren frem og tilbage på båndet). Men det er jo ikke standard C, men et bibliotek ovenpå der giver disse muligheder, så det svarer for mig at se lidt til at bruge filer eller I/O til at omgå begrænsningen, og det er jo åbenlyst muligt men ikke en del af sproget. Med EMS i C vil man have pointere "som ikke virker" når vinduet ikke peger på det rigtige, idet mange af pointerne fra C sprogets synspunkt jo overlapper. Så jeg synes egentlig ikke EMS spiller specielt godt sammen med C, det er mere en "kludge" ovenpå. Ved ikke om visse C compilere tilbød specialsupport, så f.eks. den selv kunne indsætte kode til at flytte vinduet når nødvendigt. Det ville i så fald have spillet dårligt samme med multitrådet programmering, men det gør EMS nok i det hele taget. Desuden kunne jeg forestille mig pointere til buffer-vinduet skal angives som "volatile" og man må så håbe det afholder compileren fra at lave numre med at ombytte operationer m.m. (så f.eks. en skrivning til hukommelsen blev udskudt til efter vinduet var flyttet, så skrivningen sker til det forkerte sted!). Dette koster så tilgengæld på ydelsen, da visse optimeringer ikke længere er mulige). Men måske compilerne ikke lavede så mange julelege dengang.
Hej Torben, jeg er enig i dit svar i.f.t. Kjelds indvending. Den uendelige lagerplads for en enkelt maskine er det centrale, ikke blot muligheden for at maskinen kan have en vilkårlig stor, men endelig, lagerplads. F.eks. er stop-problemet løseligt hvis pladsen er endelig, da programmer der ikke stopper, vil være nødt til før eller siden (i endelig og endda på forhånd opad begrænset tid) at gå ind i en tidligere tilstand, hvilket kan bruges til at genkende den slags progarmmer.
Når det er sagt, så mener jeg faktisk, jf. mit tidligere indlæg, at C som programmerings-sprog er Turing-komplet, idet det er muligt at implementere en C-fortolker der vil tilbyde programmer at bruge uendelig plads, sålænge programmernes output (hvad enten det er I/O eller baseret på returværdien af main-funktionen) ikke afhænger af den konkrete størrelse af typer, og det er en riemlig antagelse idet output'et ellers alligevel ikke er definerbart ud fra C-standarden alene :)
Finn: Det er korrekt at man ekstra niveauer af indirection kan man opnå ubegrænset plads. Men C har jo netop ikke disse levels af indirection - når man f.eks. foretager indirection i.f.t. en pointer, *p, for at tilgå det den peger på, så kan man kun specificere selve pointeren, p, man kan ikke specificere et segment-register eller lign. Så det du foreslår er en udvidelse af sproget C, og der vil man selvfølgelig godt kunne opnå ubegrænset lagerplads. F.eks. Java tillader ubegrænset lagerplads idet pointer-størrelsen ikke er synlig for programmet, og programmet ikke kan se selve pointer-værdierne. En pointer er abstraheret væk fra programmet. Bemærk at JAva har en begrænsning på array-længder, men det er ikke i sig selv et problem. F.eks. kan man jo stadig lave hægtede lister m.m. af ubegrænset længde. C's problem kommer af at pointer-værdierne og størrelsen af typen er direkte synlig for programmet.
Hvis C skulle udvides ville en segment-register mekanisme i sig selv ikke være nok, da det kun udvider adresserummet med en endelige faktor (ved effektivt at gå fra én pointer af endelig størrelse til en sammensætning af to pointere af endelig størrelse). Så for at gå den vej ville man være nødt til at indføre en form for "pointer-array" d.v.s. at man ville kunne adressere i.f.t. et "array af pointere" i stedet for bare "pointere" hvor adressen så findes ved sammensætning. Der må ikke være nogen begrænsning på længden af sådanne pointer-arrays for ellers komme vi ikke ud af den endelige suppedas. Så man kunne definere et pointer-array ved, at være en følge af normale pointere hvor øverste bit i hver pointer angiver om det er den sidste eller der kommer yderligere pointere (ligesom i UTF-8 enkodning). Den effektive adresse er da sammensætning af disse pointere strippet for deres første bit. Der skal som minimum tilføjes specielle alloc/free funktioner der kan returnere sådanne pointere på forlangende- de funktioner skal returnere en pointer til pointer-arrayet som så i sidste ende udpeger arealet der blev allokeret osv. Ideelt set burde man også indføre en ubegrænset heltalstype der kan bruges som argument til allco/free, men det er jo næsten snyd. Og det vil være muligt et program at humpe sig igennem og få adgang til uendelig meget lager via disse begrænsede faciliteter, f.eks. via hægtede-lister, men det vil være ganske svært at programmere i dette sprog, bl.a. fordi pointerne jo bliver længere og længere og man ikke nødvendigvis kan forudse hvor lang en pointer malloc() vil returnere næste gang, hvilket besværliggøre allokering af plads til liste-elementerne da de jo skal rumme referencer til nsæte element i listen.
Hej Troels
Enig i at generel I/O nok kan udgøre et problem, men tror egentlig det kan løses for hver enkelt forelagt API. Sålænge man ser på deterministiske programmer (og Turing-modellen er deterministisk) så må programmet jo gøre alt ens sålænge alt input er ens, og man skal derfor blot replaye alt input og ignorere alt "gammelt" output ;)
Mht. begrænsningen om at programmet ikke må være følsomt overfor ændringer i størrelser, så er det rigtigt at dette definerer et subset af C-programmer, men omvendt kan man sige at det allerede i dag er et krav at et C-program ikke er følsomt overfor størrelse hvis opførslen skal være veldefineret ift. sprog-definitionen (dvs. afvikles ens på alle C-implementationer) så på den måde er det ikke et nyt krav :-)
Man kan selvfølgelig også forlænge lageret til uendelig via de principper som Baldur/Troels diskuterer, men her kan man dog sige det er snyd, idet det ikke er sproget i sig selv, men blot hjælpebiblioteker, som mit forslag ikke betjener sig af. Man behøver ikke engang malloc for mit forslag idet man kan lade programmet anvende rekusion m.m. til at allokere dynamiske mængder af lager (som så i praksis er implementeret ved re-gennemløbs-strategien nævnt ovenfor).
Troels ang. 2**(sizeof(void*)) så mener du vel 2**(8sizeof(void)) bytes lager :-)
Anyway, jeg sidder og tænker på om der er smuthul. Forestil dig en C fortolker(der måske er et program der afvikles på en "ægte Turing-maskine" d.v.s. med uendelig meget plads) der afvikler det givne C program. Til at starte med lægger fortolkeren sig fast på én bestemt endelig værdi af sizeof(void*) og iøvrigt størrelsen af andre typer, og oplyser disse værdier til programmet på forlangende. Hvis det på noget tidspunkt sker at programmet allokerer så meget data, at størrelsen på adresserummet ikke er tilstrækkelig, så vil C fortolkeren stoppe programmet, og oprette et nyt adresse-rum med endnu større-pointere (f.eks. dobbelt så lange) og passende justering i typer. Den vil herefter simulere afviklingen af det oprindelige program igen og vil nu oplyse de nye størrelser til programmet. På et tidspunkt når simuleringen til punktet hvor programmet tidligere blev stoppet og afviklingen vil herefter kunne fortsætte idet der nu er mere plads. Det kan selvfølgelig tage lang tid, men kun endelig tid. Proceduren gentages hvis man igen løber tør for lager. Dette kan endda lade sig gøre i en model med simpel I/O (f.eks. kommunikation med brugeren via en konsol) idet C fortolkeren blot skal genspille alt input fra slutbrugeren overfor programmet. Fortolkeren skal også gemme alt tidligere output så den på passende vis kan "undertrykke" det initielle output så det ikke vises for slutbrugeren igen. Da fortolkeren jo selv har uendelig meget plads til rådighed, er det ikke noget problem at gemme alt det foregående input. Fra brugerens synspunkt vil alt se ud som om programmet virkelig har uendelig meget plads til rådighed, pånær at der er nogle pauser ind imellem, men det kender man jo også fra andre programmeringssprog med garbage collection og dynamiske arrays.
Man kunne nu have den indvending, at dette kan give problemer for programmer hvor de konkrete størrelser af pointere m.m. påvirker programmets opførsel, og som derved vil opføre sig anderledes under de efterfølgende gennemløb og evt. ikke printe samme output ud - hvorved det bliver umuligt for fortolkeren at finde ud af hvad der er nyt/gammelt output. Det kan jo også være programmet går helt ind i helt andre forløb. Disse programmer vil ikke kunne afvikles korrekt, så opførslen må være udefineret. Det er derimod ikke noget problem at programmet aktivt bruger sizeof f.eks. til at allokere storage med malloc() eller implicit ved erklæring af structs osv. idet det hele jo justeres med ved de efterfølgende afviklinger. Så man er blot nødt til at lave den restriktion at programmet skal fungere ens uafhængigt af størrelsen af de forskellige typer og blot "samarbejde med systemet" d.v.s. allokere plads ud fra hvad den får oplyst af sizeof() m.m. Men det virker som en rimelig restriktion når man stiller krav om Turing-komplethed. Og under alle omstændigheder vil det være muligt at skrive et C program der overholder denne restriktion, og som samtidigt implementerer en universel Turing-maskine (inkl. uendeligt bånd) :-) F.eks. en UTM der indlæser specifikationen for en anden maskine fra standard input, simulerer afviklingen heraf, og printer slut-tilstanden ud (hvis ellers den indlæste Turing-maskine terminerer). Dermed er det vist at C er Turing-komplet, idet det er muligt at implementere en Turing-maskine i sproget (forudsat at implementationen af C understøtter uendelig storage, f.eks. via algoritmen ovenfor).
En tilfældig udvikler kender ikke alle detaljer og muligheder i Apple's mekanisme til opdatering af firmware. Bemeldte udvikler kunne med fordel undersøge DFU mode.
Jeg har ikke udtalt mig skråsikkert - blot bemærket hans hjemmeside ikke beskriver forskningsemner der har noget med offentlige udbud at gøre. Det er en simpel konstatering. Jeg ville iøvrigt forvente, at dette fremgik af hjemmesiden hvis han virkelig er en kapacitet på området, sådan som jeg fornemmer du påstår.
Der står ikke noget der lyder af ekspertise i offentlige udbud.
Som jeg skrev i mit indlæg bebrejder jeg ham ikke at han ikke forudsagde udfaldet, men at han gav indtryk af at han kunne. Han kaldte det et skuespil, hvad det tydeligvis ikke var når en anden udbyder kunne vinde. Det er jo netop det der ligger i min kritik af at udtale sig skråsikkert - det er (burde være) alment kendt mange faktorer kan afgøre et udbud. Det er ikke så svært at forstå :)
I 2014 kaldte Version2's "ekspert", professor fra ITU Søren Lauesen, ellers hele udbuddet for et skuespil fordi CSC ville vinde. Han fik ikke ret. Det er måske værd at følge op på. Man bør i mine øjne ikke udtale sig så skråsikkert om noget man ikke har forstand på. Og man bør ikke ukritisk bringe den slags videre, sådan som Version2 har gjort.
KMD vandt udbuddet så professoren Søren Lauesen fik ikke ret. Utroligt forskere bliver fremført i medierne som "eksperter". Fat nu at "professor" ikke betyder andet end at man er ansat på et universitet. Hvad var denne professors baggrund for at udtale sig? Oh well, bekræfter blot alle fordomme om hvad ITU er blevet til.
Jeg bebrejder naturligvis ikke "professoren" han ikke kunne forudsige udfaldet. Jeg bebrejder ham at han udtalte sig så skråsikkert - han havde tydeligvis ikke ret.
Hej Kristian
Det var dog et på én gang trist og også utrolig selvhævdende indlæg. Men jeg gætter på du er et produkt af de tidlige 90'ernes ungdomskultur hvor "nørd" nok var det allerværste man overhovedet kunne være, måske bortset fra pædofil og lignende. Og det er nok derfor du "altid har anstrengt" dig for ikke at blive opfattet som nørd (hvilket er det jeg opfatter som det triste).
Men i virkeligheden er hele diskussionen dybt forældret og gammeldags, og måske mere udtryk for skribenternes alder. Hvis du tager de unge i dag - "millenial" generatonen - er "nørd" ikke et skældsord, og det er måske endda lidt cool at være nørd, hvis man arbejder med noget spændende. Det kommer selvfølgelig an på hvordan man definerer nørd - den klassiske med firkantede briller og skovmandsskjorte er jo - som du selv skriver - uhyre sjældent og er nok heller ikke scorekongen i dag. Slidte jeans/t-shirt og måske uglet hår, er måske den mere realistiske nørd på arbejdsmarkedet, og det er nok mere accepteret i millenial-generationen. Se fx en hipsterfest :-)
Men én ting er hvad ungdomskulturen synes - hvordan er det for kunderne? Det kommer nok an på branchen. Er man "management consultant" eller lign. skal man nok helst ikke ligne en nørd - der handler det mere om at være med på den nyeste mode eller i det mindste være MacKenzie casual. Man skal se "dyr" ud. For hvis man ikke har det med sig, hvad er man så værd når det hele er varm luft (i hvert fald noget af de) ;-)
Men jeg har også set det omvendte - kunder der er blevet irriteret fordi en leverandør har sendt for mange jakkesæt ind og for få teknikere, især hvis kunden måske har siddet med et komplekst problem og egentlig bare gerne har villet have leverandøren sendte den skarpeste tekniker ind for at løse det ASAP, og ikke var interesseret i snak og bortforklaringer. Eller hvis de gerne vil diskutere nogle detaljer i en kommende løsning med en kvalificeret tekniker, og der så kommer salgsfolk ind der spiser dem af med varm luft, og ikke kan forstå deres problemstilling. Selvfølgelig er alt det med påklædning funderet i fordomme, uanset om det går i den ene eller anden retning, men diskussionen handler jo om den umiddelbare signalværdi.
Når alt kommer til alt, er det selvfølgelig noget begrænsende hvis en tekniker ikke kan sætte sig ind i kundens behov. Men det er jo et helt separat issue fra mange af de andre nørd-attributter. Og hvor hyppigt er det egentligt? Jovist, jeg har også mødt teknikere - og iøvrigt også ikke-teknikere - der aldrig skulle kommunikere med kunder, for man vidste aldrig hvad de kunne finde på at sige. Og ja, der er nogle der har svært ved at sætte sig ind i kundens behov. Men de fleste udviklere der pt. er i beskæftigelse har nu efter min erfaring en god forståelse af kundebehov og at de skal retfærdiggøre deres værdi, og kommunikere hvad de laver osv. En virkelig enspænder kun kan nogle få tekniske ting tror jeg er nærmest ikke-eksisterende på dagens arbejdsmarked. Ved ikke om det kan være anderledes i forskermiljøerne, men tvivler.
Og skulle man skyde nogle fordomme den modsatte vej, kunne man sige at "sælgertyper" måske har en interesse i at udstille nørderne. De skal jo retfærdiggøre deres egen værdi og forklare deres ledere, at nok kan de ikke det tekniske, men så kan de tale kundens sprog osv. Og det er måske noget nemmere for sælgeren at tale "kundens sprog" (= sproget hos ikke-teknikerne hos kunden) sprog, når det heller ikke forlanges at de skal gå i nogle detaljer eller substans, endsige at det de siger skal være sandt :-) Men kunden ville nok heller ikke være tilfreds i længden, hvis diskussionerne forblev på dette niveau, for så ville der næppe blive realiseret en løsning.
Min holdning har altid været - alle roller, personlighedstyper m.m. (både i og udenfor arbejdsmarkedet) har både gode og negative konsekvenser, om ikke andet så i form af "hver ting til sin tid". Man kan ikke samtidigt være teknisk og ikke-teknisk, eller detaljeret og ikke-detaljeret samtidigt, og hver eneste attribut man kan have vil i nogle scenarier være en fordel og i andre scenarier en hæmsko. Man kan ikke finde en måde at være på som er optimal i alle situationer, og man kan ikke please alle til enhver tid. Og gudske tak og lov for det!
Jimmy, det kan være meget rigtigt at fra slutbrugerens synspunkt er det den samlede ydelse osv. Men går man ind på det spor, d.v.s. at benchmarken skal være en sum af CPU + en masse andre ting i systemet, så er der absolut ingen objektiv sandhed, og det er derfor ikke overraskende at man kan få vidt forskellige resultater. Du kan få præcist den procentuelle forskel du ønsker mellem 0% og X% hvor X er forskellen for en fuldstændig CPU-bound task (at CPU'er så også kan have forskellige tasks de hver især er gode til er en anden snak, men det er ikke det AMD kritiserer eller bringer frem). Der er ingen af tallene mellem 0% og X% der er objektivt mere rigtige end de andre.
Når der som du siger er meget stor forskel mellem hvad benchmarkene viser, så er det blot fordi AMD halter meget efter Intel, og at derfor er en stor underliggende forskel, d.v.s. X er stor, således at der er et meget stort udfaldsrum for resultatet.
Om AMD er value for money m.m. er en helt anden diskussion, end at AMD anfægter ærligheden af benchmarkene.
En uærlig benchmark ville være én der viste Intel's kørte hurtigere fordi den var tunet specifikt til Intel. Jeg synes derimod det er aldeles påfaldende at en CPU-fabrikant hævder, at en benchmark er vildledende blot fordi det den måler er CPU-bound! ;-)
Morten Faurholt