Udtrykket "24x7x365" giver ingen som helst mening! Enten er det "24x365", "24x7x52" eller "24x30x12".
Derudover vil jeg så sige, at jeg ved godt, hvor mange timer, der er på et år, men det interessante er, hvor stor en procentdel af den tid, tjenesten tillades ikke at være i funktion, hvor lange afbrydelserne må være (i absolutte tal!), og hvilken erstatning jeg får, hvis dette ikke overholdes.
Thomas
Hvis man ser på de adresser der allokeret så følger de altså ikke dette mønster. Man kan finde allokeringerne her: ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt[/quote][quote]
En Aggregatable Global Unicast Address ser sådan ud:
001 TLA(13) res(8) NLA(24) SLA(16) / Host(64)
Ja, jeg fik vist del noget gammelt viden. Den der TLA/NLA-opdeling er man siden gået bort fra. Det er nu op til RIR'erne at uddele efter skøn.
Thomas
... hvor meget 2^128 er. Så er det på plads. Lad os så tale om IPv6 i stedet for.
Der er ikke 2^128 unikke adresser i IPv6. Der er et adresserum, der er 2^128 stort, sådan at det er muligt at segmentere det rationelt. Kig på disse tal en gang (de er stadigvæk store, men der er en forklaring):
IPv6-adresser har forskellige formål. Nogle af dem er til multicast, nogle af dem er til link-local-adresser og nogle er til kompatibilitetsmapning af IPv4. De adresser, der fylder mest, er Aggregatable Global Unicast Addresses svarende til offentligt routebare IPv4-adresser. De udgør en ottendedel af det samlede adresserum, de andre tilsammen udgør 1%. Altså er over 85% af det samlede adresserum ikke tillagt nogen anvendelse endnu. Hvis vi har skudt os selv i foden, så har vi kun skudt os 15%.
Som nævnt består unicast-adresser af en hostdel på 2^64. Formålet er, at man kan(!) mappe direkte mellem MAC-adresser og og IP-adresser, og det ikke er nødvendig at skalere adresserummet efter, hvor mange hosts, der skal dele samme broadcast zone. Det er en feature!
En Aggregatable Global Unicast Address ser sådan ud: 001 TLA(13) res(8) NLA(24) SLA(16) / Host(64) Den første del er prefiks for AGUA-området. TLA er 13 bits til Top Level Aggregators, altså typisk backbone providers, hvilket giver ca. 8000. Hver TLA har i alt 24 bits til at fordele mellem Next Level Aggregators (deres kunder, ISP'er), hvilket er 8 millioner potentielle /48-kunder. Om vi først løber tør for TLA kombinationer eller NLA område, ved vi ikke, derfor ligger der et reserveret område på 8 bits midt i det hele. Det sidste 16 bits er til slutkundernes anvendelse, hvilket rigtigt nok er 65536 nets.
Vi er løbet tør for IPv4-adresser. Men længe inden vi løb tør for IPv4 adresser, fik et andet problem: Fragmenteringen af adresserummet, hvilket resulterede i en eksplosion af routeningsregler i backbone-routerne. Lad mig illustrere det med postnumre. Hvis vi var ved at løbe tør for postnumre, kunne vi risikere, at nye postdistrikter på Sjælland fik postnumre, der begyndte med 9xxx. Snart ville det være en kæmpe opgave at afgøre, hvordan regionalpost skulle viderebringes til andre postkontorer. Det er det, man vil undgå med det store adresserum.
Den sidste ide er ikke fundet på endnu. Hvis vi kan bruge IPv6-adresser til nye formål, så er der plads til det.
Thomas
Jeg har tit set den påstand, men det er ikke rigtigt.
Hvis man laver et afledt værk af kildetekst, og de vilkår, under hvilket man har adgang til værket, er baseret på GPL, da skal man gøre den afledte kildetekst tilgængelig for dem, man distribuerer det til. Man må overdrage kildeteksten på et passende medium helt uden at gøre det tilgængeligt for andre end aftageren,
Sagt på en anden måde: Anders laver et program og lægger det i kildetekstform på sin webserver til brug under vilkårene i GPL. Benny downloader kildeteksten og bruger det til at løse en opgave for Carl, som betaler ham penge. For ikke at overtræde betingelserne i GPL, giver Benny Carl en CDROM med de modificerede kildetekster. Anders erfarer dette, og han vil gerne have ændringerne udleveret. Men hverken Benny eller Carl er faktisk forpligtet til at udlevere dem, så længe Carl faktisk har fået dem overdraget.
Sådan er det.
Thomas
Der er forskel på snyd.
I det nuværende system er der nogle enkelte svagheder, som kan give anledning til snyd. Men de er svære at udnytte til en samlet fordel.
Det er værre med systemer, hvor en svaghed kunne påvirke en stor procentdel af stemmeoptællingen i en bestemt retning.
Men en optisk scanner, som foreslået af Carsten Olsen kl. 8:25, giver både hurtig optælling og en meget høj transparens. Det vil være min anbefaling.
Thomas
(Som også er sur over, at blanke og ugyldige stemmer opgøres i samme tal. Jeg vil for @#$%! have lov til meddele, at jeg ikke finder nogen af kandidaterne egnet!)
Man kan for eksempel (rent hypotetisk) have stor sympati, tillid og respekt for Retsforbundet.
Det behøver ikke at være spor hypotetisk. :-)
Det fornemmeste (og mest besværlige) præferencebaseret valgsystem er STV. Det sikrer, at ens stemmeseddel får en millimeterafmålt indflydelse på valgresultatet, uanset om man stemmer på en meget populær kandidat eller en meget usikker kandidat som førsteprioritet.
Læs mere om det her: http://en.wikipedia.org/wiki/Single_transferable_vote
Et sådan system vil virkelig have gavn af en elektronisk optælling. Især fordi der skal laves en ny kalkule, når der skal indsættes en suppleant.
Thomas
... om, hvilke ændringer der berettigede til, at efterfølgeren for 2.9 skulle hedde 3.0:
[i]We don't play the numbers game[/i]
Thomas
... offentligt kritiserer deres ægtefælle er til grin: De har selv giftet sig med vedkommende og evner ikke at løse problemerne inden for hjemmets fire vægge.
Folk, som vedholdende kritiserer politikere over en bred kam, er også til grin: De har selv valgt dem, og de har tilmed mulighed for at melde sig ind i et parti og deltage i processen.
Hvorfor går IT-folk ikke ind i politik? Både højre og venstre side af Salen kunne jo godt bruge et par eksperter.
Thomas
Det er nok, som du siger. Hvad tallene kan bruges til, er jo så en helt anden diskussion. Det er jo lige som [indsæt dårlig bilanalogi...]
Thomas
Tænk at kunne måle antallet af Linuxinstallationer. De er godt nok skrappe! Hvad udgør en Linuxserver? Er det antallet af CPU-cores, som afvikler en Linuxkerne, er det antallet af funktionelle tjenester, som fremstår for omverdenen som værende en Linuxserver, eller er det antallet af installationer i drift, virtuelle eller ej?
Lad os tage et eksempel: Vi har en sky af 16 fysiske maskiner. I den sky kører 10 virtuelle maskiner, som hver har 100 shared kernel instanser. Er svaret så 16? 10? 26? 1026?
Jeg kan ikke svare på det. Hvor tæt skal to bunker sand ligge på hinanden, før det er en bunke?
Thomas
Inden der tændes for mange bål om CAcert.org og Mozilla, så anbefaler jeg, at man læser dette specifikke indspark #158 fra Ian Grigg:
https://bugzilla.mozilla.org/show_bug.cgi?id=215243#c158
Det er der, sagen står (stadigvæk). Det er CAcert.org, som har trukket deres ansøgning tilbage, indtil audit-processen er afsluttet. Se eventuelt deres wiki:
http://wiki.cacert.org/AuditToDo
Der er altså ikke tale om ondskab eller smøl.
Thomas
Skulle jeg have brugt øl i stedet ? [/quote][quote]
En langtløbende diskussion vil på et eller andet tidspunkt resultere i, at den ene part fremkommer med en analogi om biler.
Haha, øl er godt. :-) Din analogi er god nok, der er bare tit bilanalogier i debatten her, og nogle af dem falder bedre ud end andre.
Det er nemlig med analogier som med biler: Når de bliver slidte, så støjer de mere i debatten :-)
Thomas
Det er lidt som med en bil, en større motor kræver også at resten af bilen er sized efter motoren. Det være sig bremser, sikkerhedsudstyr, dæk, gearkasse etc.
Godwin law for Version2:
En langtløbende diskussion vil på et eller andet tidspunkt resultere i, at den ene part fremkommer med en analogi om biler.
Thomas
I embedded systems er MIPS da ganske levende. Broadcom har en helt serie af SoC'er (system on chip) med MIPS herunder BCM47xx, som findes i WRT54GL. Men også NEC, Marvell og Phillips har en serie MIPS SoC'er.
Men ARM-arkitekturen er stærkt dominerende over både MIPS og PowerPC på embedded systems i dag.
Thomas
Torben skrev:
Sandsynligvis hverken eller. Her er nogle mere sandsynlige fejlkilder:</p>
<ol><li>
<p>Man forsøger at lave nyudvikling i et marked, hvor den mest kost-effektive løsning er brug af billig shrink-wrap software.</p>
</li>
<li>
<p>Man udvikler med forældede/uegnede sprog og værktøjer, så man bruger alt for mange programmørtimer til at løse opgaven.</p>
</li>
<li>
<p>Programmørerne er for dårlige. Diverse undersøgelser tyder på, at rigtigt gode programmører kan kode mere end 20 gange hurtigere end middelmådige programmører og alligevel (eller måske netop derfor) producere bedre kode. Så det kan sagtens være dine programmører, der fordyrer produktet. Desværre kan det ofte være svært for managers at se forskel på gode og dårlige programmører, specielt hvis de kun har erfaring med de dårlige. Så vil de gode programmører se ud som anarkister, der nægter at følge kodepraksis, og som hele tiden vil lave om på kravspecifikationerne.
Jeg var ved at skrive nogle af de samme pointer i afsnittet over, men indlægget var allerede langt nok i forvejen.
På spørgsmålet om forholdet mellem kvalitet og pris var min pointe, at den forhandlede pris, som projektet ender med at blive solgt for, ikke på magisk vis kan ændre tiden, der går til at implementere løsningen med samme indhold. Om man vil tage opgaven alligevel, afhænger af en række forretningsmæssige faktorer (f.eks. at man har folk stående på græs), men så må man bogføre det som tabsbegrænsende aktivitet.
Prisen på en vare i et givent marked bestemmes af faktorer som udbud, efterspørgsel, præferencer og tilgængelighed. Alt andet lige (herunder egnetheden af værktøj og kvaliteten af egne evner) betyder det, at aktører kan være tvunget til at justere deres priser til de nuværende vilkår. Forhåbentlig har markedet for specialsoftware tilstrækkelig priselasticitet til, at mængden af projekter stiger, når prisen falder. Det er tilfældet, hvis der ligger en bunke skuffeprojekter, der af økonomiske hensyn er skrinlagt. Hvis priselasticiteten derimod er meget lav, så kan prisen falde meget mere.
Hvad man derimod ikke kan, er at bilde sig selv ind, at man kan levere en ringere vare, når priserne generelt er faldende i markedet. At fortælle sine udviklere, at de skal implementere det samme projekt på den halve tid, fordi man kun kunne opnå den halve pris, er misforstået økonomi. Hvis de kan implementere projektet tilfredsstillende på den halve tid, så skulle de kunne gøre det alligevel - uanset pris, og kan de ikke, så har man bare hældt vand i øllet for sine kunder, hvilket de klart ikke vil betale for, når de er stillet noget andet i udsigt.
Det er kun i den situation, hvor den specifikke kunde har ønsket at begrænse sine omkostninger ved at nedsætte sine kvalitetskrav, at man kan hælde vand i øllet.
Thomas
Storm P. har en flue, hvor en mand siger: "Det kræver ærlighed at sælge elastik i metermål."
At sælge softwareprojekter er som at sælge elastik i metermål, for der vil altid være åbne parametre, når man indgår aftalen, og netop forståelsen af kvalitetsbegrebet afhænger af øjnene, der ser.
Er det dårlig kvalitet, at designet ikke tillader flere brugere adgang samtidig? Er det dårlig kvalitet, at der ikke er en turingkomplet konfigurationsfil? Er det dårlig kvalitet, at applikationen skal genstartes, hvis man ændrer i visse parametre? De spørgsmål kan ikke besvares uden at vide, hvordan softwaren tænkes anvendt. Det er et stik i hjertet, når man som programmør hellere ville lave den fulde pakke, men hvis kunden aldrig har mere end en bruger på af gangen eller sjældent ændrer i indstillingerne, har han bare fravalgt noget, der ikke giver ham værdi. Det er derfor vigtigt at gøre sig klart, om "lavere kvalitet" her betyder "reduceret funktionalitet" eller "stressforårsaget sjuskefejl".
Ofte er kvalitetsdilemmaet en konsekvens af, at der er gået vandfald i et projekt. Alle er enige om, at vandfaldsmodellen i dag kun har meget begrænset berettigelse, men når en kunde står og siger: "Kan I lave mit projekt her for X kroner?", er det svært at sige nej, især som markedet er lige nu. Men konsekvensen af et ja er jo, at man har rigtigt svært ved at få alle vores gode agile metoder i spil. Vi kan ikke længere justere på indholdet, og kvaliteten bliver elastikken i projektet, fordi den oftest ikke er en del af projektbeskrivelsen. Det er desværre en lose-lose situation, for kunden får et dårligt resultat, og det giver ikke et godt rygte i branchen. Hvis man derimod kan få kunden til at acceptere indledningsvis at købe så lidt som to agile programmører i en uge (afhængig af projektet), får han netop så meget funktionalitet, at han kan vurdere, hvor meget elastik han får pr. løbende meter. Det giver ham en langt bedre platform, hvorfra han kan træffe sine valg.
En del af problemet er også, at vi ikke helt har indset konsekvensen af, at markedet har ændret sig. En programmørtime kan ikke sælges for det, den kunne for 2-3 år siden. Hvis ikke vi har en ærlighed over for os selv om det, bliver vores regnestykker forkerte og urealistiske. Sagt på en anden måde: Hvis vores ærligste estimater siger, at et projekt koster X programmørtimer à Y kroner i timen, men at det kun kan sælges for det halve, er det så X eller Y, der er forkert?
Uanset det nævnte, er det i sidste ende kundens suveræne afgørelse, hvad han vil bruge sine penge på. Vi kan ikke gøre andet end at klargøre, hvad konsekvensen er af de valg, han træffer. Vores integritet ligger i, at vi er ærlige, gør vores bedste og - i yderste instans - siger fra, når kundens forventninger er helt uden for rækkevidde.
Thomas
Man burde langt hellere bruge det langt mere mundrette udtryk: Pennegrænsefladebetjente rejsedatamater.
Er der forresten nogen, der har set apotekernes nye tablet-PC'er, som kan håndtere receptpligtigt medicin? Utroligt, hvad man kan nu om dage.
Thomas
En Linux-bruger ville aldrig finde på at:
- Køre "./configure;make install" på en tilfældig *.tar.gz-fil fra SourceForge som root.
- Tilføje et tilfældigt APT/YUM-repository med "alle de fede codecs".
- Copy/Paste en tilfældig snippet fra Nettet, man ikke forstår.
- Installere tilfældige PHP-applikationer og give dem alle rettigheder, de skal have, for at kunne køre.
Nej, det er der ingen Linux-brugere, der kunne finde på.
:-P Thomas
Jeg vil bare nævne at der også er en del job som "it-superbruger" især i mindre firmaer, hvor man kan sætte powerpoint-temaer op, virusjagte, undervise, supportere og lave lignende småopgaver, som den almindelige befolkning ikke kan overskue. Det er vel trods alt også mere attraktivt end at vende hamburgere.
Man skal helst finde noget, der er tættest på det, man gerne vil lave. Men det godt at begynde et sted.
Jeg var på et tidspunkt kommet ind sådan en dagpengefælde, hvor jeg følte mig frustreret, ydmyget og låst. Min vej ud var, at jeg tog et job som nattevagt. Da jeg var ude af dagpengesystemet, søgte jeg ind på datalogi på KU. Jeg er uddannet svagstrømsingeniør, men der måtte altså ske noget. Relativt kort tid efter fik jeg arbejde som telefonsupporter og it-altmuligmand. Efter et år fik jeg et job, som jeg var i over 10 år. Det havde jeg ikke fået, hvis jeg var blevet på dagpenge.
Alle menneskers historier er forskellige, men der er dog et mønster: Det er bedre at bevæge sig i den forkerte retning end at stå stille.
Thomas
Jeg kender mere end et par håndfulde, som er jobsøgende og har været det i gennem noget tid. Mine råd til dem har været og er:
Kom ud af dagpengesystemet så hurtigt som praktisk muligt! Vores dagpengesystem er så ydmygende, begrænsende og uigennemskueligt, at man tager varigt skade. Man kan gøre alt det, der er forbudt at gøre på dagpenge, hvis man kan leve af at dele aviser ud, gøre rent eller vende hamburgere. Der er ikke så vildt mange af den slags jobs mere, men de er der.
Lav en karriereplan. Eller lav flere, plan A, plan B og et par stykker til. Som nyuddannet tænker man alt for meget på, hvilken teknologi eller branche, man vil være i. Men et meget mere vigtigt spørgsmål er, hvad vil jeg gerne have af funktioner i mit job? Det knytter meget mere an til den, man er som menneske. Hvornår er jeg i mit es? Hvad er livskvalitet for mig? Stiller man disse spørgsmål rigtigt og svarer ærligt, så åbner der sig en hel del flere muligheder for et karriereforløb.
Kontakt de steder, du allerhelst vil arbejde! Lad dem vide, hvad du gerne vil bidrage med i deres organisation. Selv om de ikke har et konkret tilbud om job, så bliver de fleste virksomheder smigret over, at der er folk, som har deres arbejdsplads som favorit. Har man mulighed for at netværke med nogen fra virksomheden og blive "ven af huset" på en naturlig måde, så er det måske døren til et job der.
Lav noget, der smager af fugl! Hvis man følger mit første råd, kommer man let væk fra det, man egentlig gerne vil beskæftige sig med. Men meningen med at komme ud af dagpengesystemet skulle jo netop være, at man kan tage småjobs, deltage i foreningsarbejde, skrive software eller bøger, uddanne sig eller hvad, der nu giver mening. Hold fast i den faglige tilknytning med næb og klør!
Find en mentor/coach/sparringspartner/..., som kan gennemlæse CV, ansøgninger og karriereplaner og give feedback. Man tænker ikke godt alene, og endnu dårligere sammen folk, som er præget af negativitet. Tænk på en i din omgangskreds, du har respekt for, og spørg pænt, om han eller hun vil hjælpe.
Det er mine råd. De er ikke revolutionerende og de indeholder ikke nogen form for genvej. Men det er der vel heller ingen, der forventer.
Thomas
Thomas Ammitzbøll-Bach