Tillykke Ubuntu

I dag bliver Ubuntu 5 år. Det var nemlig præcis d. 20. oktober 2004 at Mark Shuttleworth annoncerede den første udgave af Ubuntu, Ubuntu 4.10 “The Warty Warthog Release”.

Birthday Cake
Photo by chidorian.

Jeg har ikke selv været med fra starten, (det er faktisk uklart for mig præcist hvornår jeg begyndet at bruge Ubuntu), men det er tydeligt at der er sket meget siden 2004. Både i den tekniske udvikling, men så sandelig også i den community, som har vokset sig fantastisk stor omkring Ubuntu.

Her i Danmark er vi gået fra at være en mail liste (jeg tror først forumet og irc kanal kom til senere, uden at have gjort noget arbejde for faktisk at undersøge om jeg har ret), til at være et godkendt LoCo team, der yder support (forum, irc og mail), har afholdt adskillige Ubuntu Live! arrangementer – nu fast hvert halve år -, har deltaget i adskillige konferencer og så sent som i dag har vores podcast gruppe udgivet deres 2. podcast afsnit.

Det er dog vigtigt at huske på at Ubuntu ikke kan stå alene. Ubuntu bygger helt konkret på Debian, der er fra 1993. Linux kernen er også fra start 90’erne og GNU og FSF blev startet tilbage i 1984 / 1985. BSD (og Unix) kan trække historiske linjer endnu længere tilbage. Uden arbejdet udført af disse projekter og uden alle de frie software projekter der bliver arbejdet på hele tiden, rundt omkring på vores fælles klode, ville Ubuntu ikke have noget software at distribuere.
Så jeg vil gerne ønske Ubuntu tillykke med de 5 år (må de blive mange flere) og samtidig bruge muligheden for at takke alle der bidrager til fri og åben software.
Tak!

5 a day – Ubuntu bug triaging fortsat

Som opfølgning på min tidligere blog post om bug arbejde i Ubuntu følger her lidt mere uddybende info. Både flere (og lidt mere avancerede) bug opgaver og nogle flere ressourcer, der forhåbentligt kan gøre bug arbejdet lettere og sjovere.

Duplikats
Hvis flere forskellige bugs egentlig handler om det samme problem er der tale om duplikater, og det er praktisk at samle alt information et sted. Oftest foregår det sådan at den ældste bug forbliver åben, mens de andre bliver markerede som duplikater. Til at starte med kan det godt være svært at vide om en bug man sidder med er en duplikat, men hvis man har brugt lidt tid på bug arbejdet vil man nogle gange have en følelse af at have set den beskrevne problemstilling før – så er der nok tale om en duplikat.

duplicat

Markering som duplikat foregår i menuen ude til højre.

Link upstream
Meget få af programmerne i Ubuntu er skrevet direkte til Ubuntu. Så hvis der f.eks. er en fejl i Firefox i Ubuntu, så er den samme fejl måske også tilstede i den originale Firefox kildekode og Firefox pakken i Fedora. I disse tilfælde er det praktisk at få en bug registreret upstream og hvis den allerede er registreret så få de to bugs som beskriver det samme problem kædet sammen.
Dette foregår ved at klikke Also affects project eller Also affects distribution.

Bug squad og Bug Control
Der findes rigtig meget information på Bugs wikisiden. Her kan du finde kontaktinfo til Bug Squad, der er både en mail liste, irc kanal og Launchpad gruppe hvor man kan få hjælp og svar på spørgsmål angående bug arbejde. Alle kan være medlem af Bug Squad. Du kan også ansøge om en mentor, som altså er et erfarent medlem af Bug Squad som kan hjælpe med at sætte dig ind i en fornuftig arbejdsgang.

Hvis du føler at du har godt styr på bug arbejdet kan det være at det skulle ansøge om medlemskab af Ubuntu Bug Control.

5 a day
Hvis du har arbejdet lidt med at finde de rette pakker til bugs, der mangler en tilknyttet pakke (eller har fået tilknyttet en forkert pakke) vil du hurtigt finde ud af at det bliver lettere med tiden. Så hvorfor ikke afsætte et par minutter hver dag til lige at gøre noget godt for 5 forskellige bugs?
Dette er filosofien bag 5 a day. Hvis vi alle gør lidt hver dag burde det være muligt at holdet styr på den meget store mængde fejlrapporter som bliver indberettet mod Ubuntu distributionen.
Det handler selvfølgelig bare om at komme i gang! Hvis man er lidt glad for stats, eller måske har det lidt godt med et konkurrence aspekt, så kan man blive medlem af 5-a-day-participants/ gruppen på Launchpad. Når man har tilmeldt sig Launchpad gruppen sker registreringen om man har nået sine fem daglige automatisk. Man behøver ikke at foretage sig andet.
… men husk nu at det i sidste ende handler om at gøre Ubuntu bedre. Hvis du kun når tre bugs en dag har du stadig hjulpet – og du kan sagtens fortsætte til bug nr. 6 og 7 efter du har nået den daglige 5.

Det er nu muligt at følge med her fra dag til dag for at se om man selv har nået sine fem om dagen. Samtidig kan man, hvis man kan holde dampen oppe over flere uger, komme på nogle af de fine lister over dem der har holdt ud længst tid i træk.

Det er vigtigt at bemærke at 5 a day er blevet udtænkt for at gøre det lidt sjovere at triage bugs. Det er ikke ideen at man skal gøre noget ved bugs som egentligt ikke var behøvet, bare for at kunne tælle det med i en af sine fem om dagen. På sammen måde som der ingen ide er i at lave unødigt bug-arbejde bare for at få karma.

Man skal indrømme sine fejl…

Jeg skal være den første til at indrømme, når jeg har taget fejl.

Jeg har tidligere beskyldt DSB S-more for at videregive mine personlige oplysninger. Efter en (behagelig) samtale med en medarbejder i Datatilsynet har jeg nu fået afklaret at der er juridisk forskel på at videregive oplysninger og overdrage oplysninger. DSB (og andre) må gerne overdrage oplysninger til 3. part, f.eks. i forbindelse med analysearbejde, som DSB lige så vel kunne udføre internt. Denne 3. part må dog ikke bruge personoplysningerne i andre forbindelser end til den ene opgave, som de er blevet hyret til og skal, så vidt jeg forstod, destruere data når deres job er udført. DSB har altså juridisk set ikke overdraget mine (og andres) personlige oplysninger til 3. part.

Det ændrer dog ikke på at 3 udgaver af den samme mail er for meget, og på grænsen til spam. Jeg mener stadig heller ikke at det var specielt elegant, at afsender adressen på de oprindelige mails tilhørte Wilke, når man tænker på formuleringen i den oprindelige aftale med DSB S-more.
dsb

og du modtager kun information fra DSB S-tog

Men det lader ikke rigtig til at der ellers er noget at komme efter. Moralsk føler jeg stadig at DSB har overtrådt den aftale jeg har indgået med dem, men juridisk er det nok svært at føre bevis for.

http://www.boligforbedringer.dk/ – FAIL!

I forbindelse med renoveringspuljen (som jeg i øvrigt også mener er noget rod i mange forskellige andre henseender) er hjemmesiden http://www.boligforbedringer.dk/ blevet lanceret.

Jeg havde i dag den blandede fornøjelse at arbejde med boligforbedringer.dk, da jeg hjalp min far med at ansøge om udbetalinger fra renoveringspuljen. Min far har en mindre håndværkervirksomhed og skulle i denne omgang ansøge om udbetaling for arbejde udført for 9 forskellige kunder.

På siden for betalingsanmodning (https://byggeri.ebst.dk/betalingsanmodning.jsp) kan man læse:

Du skal være opmærksom på, at hver betalingsanmodning til en kunde kræver oprettelse af et brugernavn, som du skal bruge når du anmoder eller opdaterer anmodningen for kunden. Du skal således oprette et brugernavn for hvert tilsagnsnummer, du vil anmode om udbetaling for.

Så ikke nok med at man skal oprette sig på ny for hver ansøgning, men skal også indtaste information om det firma man ansøger om udbetaling til. Hver gang! Så i stedet for en mulighed for at oprette et enkelt sæt brugernavn og adgangskode for firmaet, og så her indtaste CVR nr., telefon, e-mail og lignende info en gang skal disse informationer indtastes hver gang. Det blev til 9 gange for min far i denne omgang, men det er da dybt tåbeligt!

Hver gang vi endelig havde kæmpet os igennem indtastningen af de mange informationer i det lidt tunge flash interface (som låste et par gange i forbindelse med upload af fakturaene) modtog vi en bekræftende e-mail.
Denne e-mail indeholder dog kun et ansøger ID og ingen anden identifikation. Ingen information om hvilken privatperson arbejdet er udført for, tilsagnsnummer, et faktura nummer eller lignende.
Denne bekræftende e-mail er altså næsten intet værd. Med et begrænset antal ansøgninger er det selvfølgelig muligt at holde styr på antallet af afsendte ansøgninger og antallet af bekræftende e-mails. Men hvis man senere har brug for at gå tilbage og undersøge en specifik ansøgning er der intet system i hvordan disse ansøger ID er knyttet til f.eks. tilsagnsnummeret.
Det tyder på hastværk i implementeringen af en løsning, som burde være blevet mere gennemtænkt.
… eller også har man også i designet af denne web-løsning haft skabelse af flere arbejdspladser i tankerne? Hvis det bliver besværligt eller tidskrævende nok at ansøge om disse penge, er håndværkerne tvunget til at ansætte mere kontorpersonale. Hovedformålet med renoveringspuljen var jo at sænke antallet af ledige i krisen.

Bug triaging

Der er mange måder at hjælpe med udviklingen af Ubuntu. Man kan hjælpe med support, ved at hjælpe andre brugere med deres problemer, man kan hjælpe med oversættelser, man kan advokere for udbredelsen af Ubuntu, man kan arbejde med dessign og brugervenlighed, man kan arbejde med fejlrapporter (bugs) …og sikkert en masse andet, som jeg glemmer.

Der skal kun en lille smule teknisk snilde og rimelige engelskundskaber til, for at kunne hjælpe med bug arbejdet. Det er ikke et arbejdsområde, som er forbeholdt udviklere.

Der er få fejlrapporter, som er direkte klar til at blive arbejdet på af udviklerne. Rigtig mange bugs indeholder ikke nok information eller er rapporteret mod forkerte pakker. Her kan alle hjælpe med. Man skal bare have oprettet sig som bruger på Launchpad og så ellers gå i gang.

Hvis en bug rapport kun indeholder information som “Firefox crasher” så er det meget svært for en udvikler at gøre noget ved det. I situationer hvor en rapport indeholder for lidt information ændres status til Incomplete og man skriver et svar hvor man udbeder mere information.
Der findes standard svar, så man skal ikke engang bruge lang tid på formuleringen.

Mange bugs bliver rapporteret mod Ubuntu generelt og ikke mod den pakke som indeholder det program der er en fejl i. Nogle gange er det oplagt, når man læser bug beskrivelsen, hvilken pakke den egentlig bør rapporteres imod. Fejl i programmer skal som hovedregel rapporteres mod den pakke som programmet kommer fra. Andre gange er det knapt så indlysende. Heldigvis er der hjælp at hente her. Hardware fejl er ofte kerne relaterede, og skal rapporteres mod linux pakken. Fejl under installationen hører ofte til ubiquity pakken. Grafik fejl hører ofte til Xorg pakken.
I bunden af wiki siden er der også info om hvordan man finder ud af hvilken pakke et program eller en fil stammer fra.

Hvis vi ser på en generel bug vil vi ovenover beskrivelsen af fejlen blive mødt af følgende på Launchpad:

1

Hvis vi vil ændre status er det blot at klikke under status, hvor der oftest ved nye bugs vil stå New.

1-status

Her er mange muligheder, men hvis man ikke er udvikler er de mest interessante for os Incomplete og Invalid. Incomplete bruges hvis der ikke er nok info i rapporten til at begynde at løse problemet og skal ledsages af en besked som beskriver hvordan den ønskede info skaffes. Invalid bruges hvis bug rapporten ikke er relevant. F.eks. hvis en fejl rapporteret mod installeren viser sig at være opstået pga. en fejlbrændt cd.
2

Hvis bug’en er rapporteret mod den forkerte pakke, eller hvis den (som det ofte sker) er rapporteret mod Ubuntu distributionen og det er klart hvad den rette pakke er (evt. med hjælp fra denne liste), så ændres dette ved at klikke på pilen til venstre som markeret nedenfor.

1-affects
Her kan man vælge den rette pakke, som omtalt ovenfor. F.eks. pakken linux, som ofte er den rette til bl.a. hardware problemer.
3-package

Endelig kan man, hvis man er nysgerrig for hvad der kommer til at ske med bug’en herfra bede om at blive underettet pr. email når der sker ændringer. Specielt hvis man er ny til bug arbejdet kan det være en god ide – både for at få en forståelse for hvornår en bug kan betragtes som færdig, men også for at finde ud af om man har fundet den rette pakke.

5-email

Så for at opsummere:

Her er en liste over bugs rapporteret mod Ubuntu og som mangler at blive tilknyttet til en pakke. Et rigtigt godt sted at starte sit bug arbejde. Der er flere lette opgaver at finde her.

Her er info med hjælp til at finde den rette pakke.

Her er en liste med standardsvar, som bl.a. kan anvendes når man vil bede den oprindelige bugrapporter om mere info.

God fornøjelse!

Endnu et svar fra DSB

Fredag d. 9. oktober fik jeg (efter en måneds ventetid og en enkelt rykker) endnu et svar fra DSB, i forbindelse med min tidligere henvendelse angående deres videregivelse af personlige oplysninger til 3. part.

Kort fortalt har DSB videregivet mit navn og min e-mail til Wilke (et analysefirma) for at Wilke kan udføre en brugerundersøgelse for DSB. Dette strider mod den aftale jeg har indgået med DSB S-More, hvor DSB lover ikke at videregive mine oplysninger.

Svaret jeg fik fra DSB følger her:

Hej Søren

I S-more videregiver vi under ingen omstændigheder de oplysninger, som vi ligger inde med om vores kunder. Vi har imidlertid indgået et samarbejde med Wilke i forbindelse med en kundeundersøgelse. Alle medlemmer i S-more, der har været logget ind indenfor de sidste 4 måneder, bliver tilbudt at være med i undersøgelsen. Formålet med undersøgelsen er, at vi kan blive endnu bedre til at servicere vores S-more-kunder. Af tekniske årsager kommer Wilke til at stå som afsender på e-mailen, men undersøgelsen omhandler udelukkende medlemskabet i S-more, og det er S-more som står bag undersøgelsen.

Som undskyldning på denne uklarhed i afsenderinformation, vil vi gerne sende dig et S-more klippekort til S-toget. Hvor ønsker du dette sendt til?

Med venlig hilsen

S-More
www.dsb.dk/s-more

Så hvis man har modtaget den oprindelige mail, ligesom mig, så kan det være der er et gratis klippekort at score, hvis man henvender sig og klager.

Jeg er dog ikke tilfreds med deres svar. De benægter at have videregivet mine personoplysninger, selvom det er tydeligt at det er det der er sket.

Mit svar til DSB (sendt i dag) kan læses her:

Hej S-More

Nej, det er simpelthen ikke godt nok. I skal ikke forsøge at gemme jer bag en “Af tekniske årsager kommer Wilke til at stå som afsender på e-mailen” formulering.

For det er ikke kun som afsender der står Wilke Online. Det handler også om at mailen er blevet afsendt af Wilke. Fra mail-header’en på den mail jeg har modtaget:

Received: from mail.wilke.dk (mail.wilke.dk [77.233.229.244])

Den oprindelige mail er altså afsendt af Wilke. For at de skal kunne sende en mail til mig må de have fået mit navn og e-mail et sted fra. I har altså videregivet mit navn og min e-mail adresse til Wilke. Om de skal bruge det til en kundeundersøgelse for jer eller noget helt 3. er jeg fuldkomment ligeglad med. I sidste ende har I videregivet oplysninger om mig til en 3. part, i klar modstrid med den aftale jeg har indgået med jer.

Jeg minder om at jeg på jeres hjemmeside har sat hak udfor:

Ja tak, jeg vil gerne modtage relevant information om ’S-more’ på e-mail. DSB S-tog videregiver ikke dine oplysninger, og du modtager kun information fra DSB S-tog

Der står ikke nogen undtagelse om at når det drejer sig om en brugerundersøgelse, så må I gerne videregive oplysningerne. Nej, der står “DSB S-tog videregiver ikke dine oplysninger, og du modtager kun information fra DSB S-tog“. I kan ikke løbe fra at I i dette tilfælde har videregivet mine personlige oplysninger.

Jeg syntes det er sølle at I forsøger at bestikke mig med et klippekort, og jeg syntes det ville klæde jer hvis I ville indrømme jeres fejl, i stedet for at tale udenom.

Mvh.
Søren Caspersen

Late Global Jam in Copenhagen

Better late than never… due to some scheduling problems we didn’t manage to run a Global Jam last weekend, as the rest of the Ubuntu community did.

However, luckily we managed to run a jam yesterday, Saturday 10. If it could be called a part of the Global Jam, or if it was just our Local Jam is really just a matter of words. The five of us ended up working primarily on bug triaging. However we also had a quick look at the features of Empathy (the new default instant messaging client in Karmic Koala), and the Ubuntudanmark Podcast guys did a quick segment for their next podcast.

All in all I think the jam was a success, and I think we are ready for similar events in the future.

New Community Council

The vote for the new Ubuntu Community Council is over, and Mark Shuttleworth has announced the results.

The new council consists of (in alphabetical order)

  • Alan Pope
  • Benjamin Mako Hill
  • Daniel Holbach
  • Elizabeth Krumbach
  • Matthew East
  • Mike Basinger
  • Richard Johnson

A total of 267 Ubuntu members have cast their votes, which gives a voter turn out of roughly 66 percent.

If you feel like diving into the numbers, all the info and all the ballots are (in an anonymised and randomised form) available here:
http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?id=E_f802a7d79840b58a

Congratulations to the new council!

Ubuntu Karmic Koala Beta

Efter 6 alpha udgivelser (som vist ikke alle har været helt problemløse) er Ubuntu Karmic Koala nu endelig kommet som Beta version.

Beta udgaver anbefales ikke til almindelige brugere, men hvis du er nysgerrig på at se hvad den næste version af Ubuntu kommer til at indeholde, eller har lyst til at hjælpe med at teste, så de sidste fejl kan blive fanget og fjernet før den endelige udgivelse, så er muligheden her nu.
Det skal dog ikke ske på en maskine, som du ikke kan undvære. Beta udgivelsen kan stadig indeholde kritiske fejl, og du skal være klar til at miste data og stå tilbage med en maskine som i værste tilfælde ikke vil boote.

Hvis det er en risiko som du er villig til at tage, så kan CD billeder hentes her:
http://releases.ubuntu.com/releases/9.10/

Hvis du vil forsøge at opdatere fra din nuværende Jaunty installation og er inforstået med risikoen så skal du blot trykke Alt+F2 og så taste:

update-manager -d

Den endelige udgave, Ubuntu 9.10, skulle efter planen blive udgivet torsdag d. 29. oktober og til den tid skulle er ikke være nogen risiko forbundet med at opdatere (selvom det altid er en god ide at have en ordentlig backup, hvis nu…).

Mere info om beta udgivelsen findes her.

Cirkus milli

Den meget omtalte oversættelse af Jæger – i krig med eliten til arabisk var først ikke lavet i forsvaret.

Det viser sig nu at det var den. Ups!

gade-small-1

Den ansvarlige (en it chef) er blevet fyret. Men har flere været involveret? Forsvarsminister Søren Gade (og andre) har jo haft meget fokus på den arabiske oversættelse, og nærmest brugt den som en indikation på at bogen har indeholdt farlige passager.
Hvis oversættelsen er blevet fabrikeret i forsvaret for at styrke ministerens argument, så er det en yderst pinlig sag!