Det var jaggu på tide

Tema: Programvare; sjanger: Meninger
Skrevet av Andreas Nordal den 17. november 2008 kl 23:03:30; Kommentarer: 0

I dag slapp Adobe en 64-bitsutgave av Adobe Flash Player. Foreløpig kun for Linux og Solaris, og fortsatt på alfastadiet. Det skjedde ikke en plancktid for tidlig, dette er en bønn som vi Linux-brukere har mast kraftig om de siste 2-3 årene. I denne perioden har mangelen på en 64-bitsutgave vært et gjennomgangstema som har druknet det meste av annen kritikk fra Linux-hold, noe kommentarene på utviklerbloggen, vitner om.

Jeg måtte selvsagt prøve den straks med min Firefox 3.0.2, og kunne konstatere at:

Lyden virker ikke.
Jeg fikk spilt en snutt på nrk.no (ikke vanlig nett-TV) og en på youtube.
Fikk firefox til å krasje da jeg trykka på en film på digi.no

Testen ble gjort med Fedora 9 uten nspluginwrapper, og kjernen heter Linux 2.6.26.6-79.fc9.x86_64.

Jeg må innrømme at med de fordommene jeg har opparbeidet meg mot Adobe, kom nyheten som litt av en overraskelse. Senest i går lykkes jeg faktisk i et desperat forsøk på å sette sammen min egen 64-bitsversjon av det fordømte programmet vha elftoc og gcc. Det ble altså et 64-bitsprogram, men det funka selvfølgelig ikke, det skal ikke være så lett. Jeg er glad jeg slipper å tenke på dette mer.

Tro ikke at problemet har vært noen bagatell. For det første kan det være vanskelig nok å få 32-bitsprogrammet til å funke, selv for Linus Thorvalds, jeg har heller ikke klart det. For det andre er det såpass mange internettsider som forventer at man har denne ufrie 32-bits-programvaren, at det ikke er til å stikke under teppet og glemme. Man minnes på det hele tiden og man føler seg enten handikappet eller utstøtt av samfunnet. For det tredje er Adobe Flash Player det siste hinderet for mange Linux-brukere, ikke bare mot bruken av 64-bits-operativsystemer, men også den generelle programvarefriheten som vi Linux-brukere gjerne er tilhengere av (jeg har for eksempel bare 3 ufrie programmer på min bærbare datamaskin, nemlig bios, skjermkortdriver og nå Adobe Flash Player). Selv om det for andre operativsystemer kan være flere grunner til å holde seg til 32 bit en stund til, er det altså ikke det for Linux.

Tro ikke at problemet er løst. Problemet er egentlig at Flash-teknologien er ufri: Bare Adobe kan fikse den, ingen andre er i nærheten av å lage noe kompatibelt, og Adobe vil aldri klare på egenhånd den umulige oppgaven å gjøre den tilgjengelig for alle. Som standard er den altså helt uakseptabel. Like uakseptabelt er det å tvinge/forvente av folk å bruke akkurat Adobes produkt ved å knytte det til egne tjenester. På lang sikt vil bare åpne standarder få markedsaksept. Adobe står bak suksessrike åpne standarder som postscript og PDF, hvis Flash skal nå samme status uten å dø som en flopp, finnes det bare én vei å gå.

Når pakkehåndtereren er for dum

Tema: Programvare; sjanger: Meninger
Skrevet av Andreas Nordal den 6. november 2008 kl 21:00:42; Kommentarer: 0

Pakkehåndterere er noe de aller fleste brukere av Linux må forholde seg til. Disse programmene lever i sin egen verden, som er nokså forskjellig fra den virkelige. Som regel har hver Linux-distribusjon sin egen pakkehåndterer, de fleste er basert på et av 2 pakkeformat: RPM og DEB. Alternativet til å bruke pakkehåndterer er å laste ned og installere ting manuelt. Det er mange grunner til at dette ofte er vanskeligere på Linux enn Windows. Derfor vil man helst bruke pakkehåndtereren, bortsett fra noen ganger når man har helt spesielle normale behov. I praksis er distribusjonene som monoteistiske religioner: "du skal ikke ha andre pakkebrønner enn meg", og pakkehåndterere er som forrige president i USA: "enten er du med oss eller så er du mot oss". Å installere fra andre kilder straffer seg i form av pakkekonflikter. Det er jo ikke uvilje, bare en teknisk utfordring som er problemet. Men når systemet gir opp, og man begynner å lure på hvor dum det går an for en pakkehåndterer å bli, da er det dårlig menneske-maskin-interaksjon at disse programmene ikke gir mulighet for brukeren til å hjelpe, i det minste til å ta riktige beslutninger. For eksempel nytter det ikke å fortelle at en fil faktisk ligger på harddisken hvis pakkedatabasen sier at den ikke gjør det. Med forbehold om at noen pakkehåndterere er smartere enn andre, og at noen kan overstyres mer enn andre, vil jeg påstå at tendensen er representativ for alle pakkehåndterere jeg har prøvd.

Pakkehåndterere tror at

de vet bedre enn deg.
det er ingen ting du kan bidra med.
du aldri vil installere ting utenom pakkesystemet.
hver eneste avhengighet er like viktig (som at libraw1394 er dødsviktig selv om man aldri bruker firewire).
det er bedre å mislykkes totalt enn å mislykkes delvis.
det er så farlig å overskrive selv uviktige filer (manualsider o.l.).
det er nødvendig å avinstallere tusenvis av pakker som avhenger av den ene pakken man har til hensikt å reinstallere (men som typisk ikke kan reinstalleres på annen måte enn å fjernes og installeres igjen i 2 omganger som i mitt tilfelle).

Problemet mitt

Fedora er heldigvis flinke til å komme med oppdateringer, men de siste ukene har jeg slitt med å installere oppdateringer for KDE 4. Problemet er at kdebase avhenger av fila libraw1394.so.8 som ligger i pakken libraw1394-1.3.0-7.fc9.i386, som ikke kan installeres på grunn av en pakkekonflikt:

package libraw1394-2.0.0-2.fc10.x86_64 (which is newer than libraw1394-1.3.0-7.fc9.i386) is already installed

  file /usr/share/man/man1/dumpiso.1.gz from install of libraw1394-1.3.0-7.fc9.i386 conflicts with file from package libraw1394-2.0.0-2.fc10.x86_64

  file /usr/share/man/man1/sendiso.1.gz from install of libraw1394-1.3.0-7.fc9.i386 conflicts with file from package libraw1394-2.0.0-2.fc10.x86_64

  file /usr/share/man/man1/testlibraw.1.gz from install of libraw1394-1.3.0-7.fc9.i386 conflicts with file from package libraw1394-2.0.0-2.fc10.x86_64

  file /usr/share/man/man5/isodump.5.gz from install of libraw1394-1.3.0-7.fc9.i386 conflicts with file from package libraw1394-2.0.0-2.fc10.x86_64

Min løsning:

Jeg kunne selvfølgelig avinstallert versjon 2.0.0 av libraw1394 for så å installert versjon 1.3.0 som jeg trengte, men da hadde jeg måttet avinstallere 49 andre pakker som avhenger av dette biblioteket, deriblant KDE, antakelig hundrevis av megabyte med programvare som jeg måtte installert om igjen. Hvis jeg fikk valget mellom det, eller å bare tvinge installasjonen til å overskrive de 4 totalt uviktige manual-filene ovenfor, så hadde jeg så klart valgt det siste. Så dum er jeg ikke, men det er tydeligvis yum (Fedoras ugrafiske pakkehåndterer). Det er ikke noe problem for meg å slette disse filene, men tingen med pakkehåndterere er at det ikke hjelper så lenge det står i databasen at de er installert. Trikset var like enkelt som det var skittent:
rpm -e --justdb --nodeps libraw1394-2.0.0-2.fc10.x86_64

Dette fjerner libraw1394-2.0.0 fra rpm-databasen, slik at de aktuelle filene nå kunne overskrives med libraw1394-1.3.0 i et nytt (og denne gang vellykket) forsøk på å oppdatere KDE. Det er et tankekors at disse systemfilene som liksom var så viktige bare ble overskrevet automatisk uten at jeg fikk vite det en gang nå som de ikke var oppført i rpm-databasen. At de stod i rpm-databasen kommer av at jeg har brukt en rpm-basert pakkehåndterer til å installere dem, det hadde de ikke gjort hvis jeg installerte dem manuelt. Hvem sier at filene til pakkehåndtereren er viktigere enn mine filer?