Herligt indlæg, jeg lærte i hvert fald en masse!
PS! Du kører routinator som root! ?
Findes der ikke en gylden middelvej? Altså en protokol som kan overføres i ren tekst og stadig være letforståelig, men som også har en binær repræsentation som er mere optimal ifht. kodestørrelse og hastighed? Her er det så vigtigt at de to har en 1:1 relation så man kan stole på at når det virker med tekstversionen så virker det også når man skifter til den binære version. Så kan man udelade den del af koden som fortolker tekstversionen fra den færdige version af de dimser man leverer.
CBOR har samme model som JSON og kan derfor mappes med passende tools.
Der kan være op til 2 parents.
Der kan faktisk være så mange parents det skal være:
Så jeg bruger Gedit, fordi dets mangler gør mig til en bedre udvikler.
På samme måder, som en tømrer er bedst hvis han nøjes med at bruge gammeldags værktøj og holder sig fra skruemaskiner og deslige?
Du tager simpelthen fejl - Anvendelse af moderne værktøjer har stor indflydelse på din produktivitet.
Eftersom man har en lille skov af den slags kasser i huset så vil jeg også kigge på strømforbruget.
Hvorvidt robotter udgør en trussel eller ej afhænger næppe af hvad vi tror. Dit andet eksempel - Eksistensen af liv andre steder i universet afhænger heller ikke af hvad vi render rundt og tror.
Jeg kan egentlig godt forstå behovet for overvågning. Før mennesket fandt på at bruge værktøj kunne det enkelte individ ikke skabe mere død og ødelæggelse end hvad vedkommende kunne klare med sin egen krop. Den teknologiske udvikling gør det enkelte individ langt mere farligt i dag. En veluddannet ingeniør/fysiker/kemiker kan dræbe rigtig mange på egen hånd. Det jeg ikke kan forstå er hvorfor denne overvågning skal foretages af hemmelige tjenester. Hvis offentligheden skal acceptere overvågning må det være et krav at vi, eller de uafhængige eksperter vi har tillid til, kan gennemskue at data skabes på en sikker og kontrolleret måde, opbevares på en sikker og kontrolleret måde og udleveres på en sikker og kontrolleret måde.
Men Mark Adler har et forslag. fitblk.c i zlib's egne examples komprimerer data til en max fast størrelse og algoritmen er dokumenteret øverst. Jeg linker blot til den for at undgå spoilers for dem som vil løse opgaven selv og ikke blot snyde:
https://github.com/madler/zlib/blob/master/examples/fitblk.c
Peter, du er ikke spor hysterisk. Her er vores C++ compiler flag:
Linux gcc: -std=c++11 -march=core2 -fno-common -pipe -Werror -Wall -Wextra -Wreorder -Wnon-virtual-dtor -Wpacked -Wcast-align -Wenum-compare -Wpointer-arith -Wunused -Wuninitialized -Winit-self -Winvalid-pch -Woverlength-strings -Woverloaded-virtual -Woverflow -Wno-unknown-pragmas -Wpacked-bitfield-compat -Wlogical-op -Wsync-nand -Wstrict-null-sentinel -Wnoexcept
Visual Studio 2013/2015: /Zc:inline /Zc:rvalueCast /volatile:iso /Zo /MP /WX /arch:SSE2 /nologo /Zm200 /W4
Derudover bygger vi også med clang og vi har cppcheck og clang-tidy på vores CI system til yderligere statiske checks. Vi har også længe snakket om at prøve Coverity og/eller PVS-studio.
Vi har brugt -Wall -Werror i mange år, mens yderligere statisk analyse værktøjer kom på bordet efter at have læst om Carmacks erfaringer i 2011:
http://www.gamasutra.com/view/news/128836/InDepth_Static_Code_Analysis.php
Men disse ting vil nok nå de højere sprog først, C/C++ vil nok forblive legacy sprog med begrænset tooling sådan som det har været de sidste maaaaange år.
Det er en forældet opfattelse. C++ udvikler sig skam stadig. C++11 er en kæmpe fornyelse af sproget og yderligere forbedringer kom til i C++14. C++17 (forventet) vil bringe yderligere forbedringer. På tooling området har Clang - tak Apple! - sørget for at der er kommet skærpet konkurrence på compiler-fronten, så gcc, MSVC har måttet oppe sig for at følge med. Clang har også vist vejen med stærkt forbedret tooling generelt.
På IDE fronten er der også sket en del. Qt Creator er efter min mening et langt bedre IDE end gamle bedagede Visual Studio, og Jet Brains CLion skulle også være et stærkt bud.
Jeg er meget enig I Peter's betragtninger om emnet - vælg en kodestandard, som allerede findes. For C++ vil jeg mene at dette relativt nye projekt af Bjarne Stroustrup og Herb Sutter er meget mere spændende end dem Peter nævner :-)
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md
Problemet er, at MD5-hashfunktionen har været regnet for usikker siden årtusindskiftet og kan rutinemæssigt brydes med brute force-angreb, hvor man forsøger sig med forskellige kombinationer af kodeord.
Nej, problemet er værre endnu. Lige som forfatteren af artiklen her så vidste udviklerne hos Ashley Madison ikke at MD5 algoritmen er aldeles uegnet til password hashing. En password hashing algoritme skal være beregningsmæssig dyr for at gøre brute force angreb uattraktive og det har aldrig været en parameter for MD5 algoritmens design - tværtimod.
MD5 må ikke blandes sammen med md5crypt, som er skrevet af vores egen PHK. md5crypt er beregnet til password hashing, men er ikke længere beregningstung nok og blev EOL'et for nogle år siden.
Vi linuxbrugere har ikke brug for lug.dk. Det lyder også til at de har spurgt pænt. Endelig er det en god organisation, som alle kan støtte op om. Giv det til dem og sig tak for deres gode arbejde
Hvad er der være galt i at det er "små inkrementelle justeringer" når de har reduceret katastroferne med en faktor ca. 50 ?
Jeg forsøger blot at bringe lidt nuance ind i debatten ved at fremhæve at en ITHK ikke er en magisk sølvkugle, og at en mulig omkostning vil være innovationshastighed.
Men hvis man faktisk har forstand på fly, vil man se at moderne fly er meget bedre gennemtænkt end dem fra 1950, f.eks indenfor sådanne områder som brandsikring, metaltræthed, nødudgange, redundans osv. osv.
Bevidst misforstået, så du kan fortsætte med at snakke om dine egne pointer. Du har en politiker i maven, tror jeg :-)
Moderne passagerfly er skåret over den samme læst som passagerjetfly fra halvtredserne. Selvfølgelig er der lavet forbedringer, men det er forholdsvis små inkrementelle justeringer.
Ideen om en IT-haverikommission kommer formodentlig fra luftfarten. Her er det værd at bemærke at et top-moderne passagerfly ikke er til at skelne fra et fra halvtredserne. Min pointe er at det er sandsynligt at en IT-haverikommision vil kunne øge stabiliteten og sikkerheden i IT-systemer, men man er nødt til at overveje hvordan det påvirker udviklingen.
Jeg er ikke afklaret ved en IT-havarikommision, men det er da en interessant tanke.
Jeg vil tro, at assemblerkode er hurtigere end C++. Det kræver en del arbejde at skrive programmer i assembler, men det kræver også en del arbejde at skrive effektive (og samtidigt korrekte) programmer i C++.
Det er selvfølgelig rigtigt at du kan skrive mindst lige så effektiv assembler, som compileren kan - Hvis du er rigtig rigtig dygtig. Men der går ikke ret mange år før din håndoptimerede assemblerkode ikke længere er så hurtig som det compileren genererer. C++ udvikleren beder bare sin compiler om at generere kode til i7 med -march=, mens du kan starte forfra med din assembler :-)
Vedr indsatsen for at skrive effektive og korrekte C++ programmer, så er den C++ din far kendte kun et levn. C++11 kode ser markant anerledes ud end ældre C++ kode.
Vh Thomas
jeg har virkelig brugt en masse timer på det spil som dreng, og nu har jeg købt det på iPad og gennemført det igen. Glæder mig til Hybris (igen)!
Jeg er et levende eksempel på at tastehastigheden ikke er afgørende. Jeg har aldrig fået mig skrumlet sammen til at lære ti-finger systemet og taster forholdsvis langsomt. Men som udvikler leverer jeg varen til fulde. Tastehastighed er ikke de der gør en god udvikler.
Ovenstående fik mig til at tænke på følgende fra Kent Beck:
I've known people who have not mastered their tools who are good programmers, but not a tool master who remained a mediocre programmer
Så det er da muligt at du er en udmærket udvikler, men det er et dårligt tegn at du ikke har valgt at bruge tid på at mestre et temmelig relevant værktøj - dit keyboard :-)
Thomas Søndergaard