Gamle versioner i Programhåndtering

Godt spørgsmål som jeg selv har tænkt på flere gange.

Jeg er endnu aldrig stødt på problemer med nyeste version hentet andre steder fra, så jeg tror ikke det er det.

Nogle gange er distroversionen bare lidt bagud, andre gange er det helt galt og kan være en mindre major release.

Nogle distroer er kendt for at være mere cutting edge end andre på dette punkt.

De fleste mainstream-distros (Ubuntu, openSUSE Leap m.fl.) følger en release-model, hvor distributionen bliver frosset på udgivelsestidspunktet - og derefter som udgangspunkt kun modtager sikkerheds- og bugfixes, men ingen nye features. Formålet med det er dels at det er meget stort arbejde at "backporte" (bygge pakker af nye programmer til en "gammel" distro) og teste alle de nye pakker og deres samspil med resten af distributionen, og dels at de fleste brugere slet ikke har interesse i at softwaren ændrer udseende, opførsel og får nye/andre bugs/features eller måske mister features hver uge eller måned.

Så kan man så opgradere til en ny distro-udgivelse 6-12 måneder senere, hvor man får alle de nye versioner. Som regel kan man også bare tilføje nogle ikke officielt supporterede repositories på eget ansvar, med de opdaterede pakker ("backports") som man måtte have brug for, for at udføre de opgaver man har brug for at udføre.

Ellers findes der jo en hel del "rolling release"-distributioner (f.eks. Arch, openSUSE Tumbleweed), som løbende opgraderer alle pakker i hele systemet til nyeste version (ikke kun programmer, men også underliggende biblioteker, kernen mv.). Hvis man synes sådan en rutschebanetur lyder tillokkende.

Helt grundlæggende har det vel noget at gøre med at Linux-distros er dynamisk linkede. Så der er en masse delte biblioteker og andre afhængigheder, der gør at man ikke uden videre kan opgradere et program uden at risikere det har konsekvenser andre steder i systemet. Teknisk kunne man godt lave nogle statisk linkede pakker, men det ville være et stort arbejde, og de ville fylde ligeså voldsomt som de gør på MS Windows, og det kunne potentielt medføre sikkerhedsproblemer osv. at have det samme bibliotek installeret en masse gange sammen med hvert eneste program som bruger et bibliotek.

#2: Formålet med det er dels at det er meget stort arbejde at "backporte" (bygge pakker af nye programmer til en "gammel" distro) og teste alle de nye pakker og deres samspil med resten af distributionen

Det er sikkert rigtigt, men ikke desto mindre så virker fx deb-pakker man downloader jo som regel ud af boksen.

#2: Teknisk kunne man godt lave nogle statisk linkede pakker, men det ville være et stort arbejde, og de ville fylde ligeså voldsomt som de gør på MS Windows

Det ville faktisk være rart med et værktøj der kunne bygge en statisk linket pakke ud fra et normalt dynanisk linket program. Det ville gøre det muligt i mange tilfælde at benytte ældre eller nyere version af et program uden at rende ind i "dependency hell".

#2: Helt grundlæggende har det vel noget at gøre med at Linux-distros er dynamisk linkede. Så der er en masse delte biblioteker og andre afhængigheder, der gør at man ikke uden videre kan opgradere et program uden at risikere det har konsekvenser andre steder i systemet.

- Præcis problemstilling:) - Et helvede at skulle installere et program, som kræver en nyere version af fx Python. Smæk så denne nyere version på. Den kræver så måske
den ældre version afinstalleret. Nu har du så fået dit nye program til at fungere. Men det er der så andre programmer som ikke gør.

- Det er en af grundene til at diverse mere eller mindre modificerede derivater af mere eller mindre rullende distroer har det med at brække halsen. Se fx den gamle LMDE eller Manjaro.

- Nogen der ved, førstehånds, hvordan det går med den polske variant af Debian Testing: Sparky?

- Nå, hvis man følger lidt med, så er det jo ikke nogen hemmelighed, at Canonical/Ubuntu med deres Snappy adresserer lige nøjagtig denne problemstilling:)

#3
En hurtig søgning på google gav mig følgende:
http://stackoverflow.com/questions/271089/how-to-statically-link-an-exi…

Der er links til flere programmer der netop er designet til det du ønsker.

#5: Der er links til flere programmer der netop er designet til det du ønsker.

Tak. Den eneste jeg umiddelbart kunne få til at virke var Ermine der kun koster - host, host - 60 USD om måneden!

De må have spist søm.

Tak for jeres svar. Jeg har også flere gange bare downloaded et program fra nettet, hvis versionen i depository har været gammel, men dermed løber man så en vis risiko, kan jeg forstå.

#7:
Generelt løber du ingen risiko hvis du downloader et program fra nettet, i værste fald vil programmet ikke virke pga uopfyldte afhængigheder.

Men selvfølgelig skal man altid lige tænke over hvor man henter det fra, så man ikke får noget snavs med, men det er en helt anden problemetatik.

#7: Tak for jeres svar. Jeg har også flere gange bare downloaded et program fra nettet, hvis versionen i depository har været gammel, men dermed løber man så en vis risiko, kan jeg forstå.

Du er hjulpet rigtig godt på vej med at installere disse Addons i browseren:
https://db.tt/UXCJEEKu

De kan installeres på Firefox, Chromium og Vivaldi Browser, formentlig flere.

Vivaldi er iøvrigt helt ny. Fra systemudviklerne bag Opera browseren:
https://vivaldi.com/

#8: i værste fald vil programmet ikke virke pga uopfyldte afhængigheder.

Kan man sige det er en konklusion på fordelen ved ikke at være bagudkompatibel, udover speed og størrelsen af OS?

#8:
Generelt løber du ingen risiko hvis du downloader et program fra nettet, i værste fald vil programmet ikke virke pga uopfyldte afhængigheder. Men selvfølgelig skal man altid lige tænke over hvor man henter det fra, så man ikke får noget snavs med, men det er en helt anden problemetatik.

Hvis man eksperimenterer med den slags, skal man i hvert fald sørge for at det er "leaf"-pakker man har med at gøre - dvs. pakker, som der ikke er andre pakker der afhænger af. Men i så fald er risikoen begrænset til at det enkelte program ikke vil virke.

#10: Kan man sige det er en konklusion på fordelen ved ikke at være bagudkompatibel, udover speed og størrelsen af OS?

Der er store fordele for udviklerne. Forestil dig hvor mange ressourcer Microsoft bruger på at sikre at gamle binaries fra sidste årtusind stadig kan køre, og hvor meget cruft (inkl. sikkerhedsrisici) det trækker med i systemet?

Jeg havde i øvrigt også fornøjelsen af at have brug for nogle gamle PPC-binaries (i en arbejdsmæssig sammenhæng), kort efter Mac OSX droppede deres kompatibilitetshalløj - så det er ikke kun på Linux man møder problemet. Jeg havde også en gang en printer fra Windows 98-dagene, der kom ingen driver til Windows XP og de gamle drivere kunne ikke bruges - så der var kun helt basal funktionalitet med en standarddriver.

Og som det har været nævnt, er det ikke fordi det ikke er teknisk muligt at lave nogle statisk linkede binaries, det er bare et spørgsmål om ressourcer og om det er umagen værd. Og rigtig mange programmer kan jo også relativt uproblematisk backportes - som man ser ved at de faktisk er nemt tilgængelige i diverse 3.partsrepositories.

#12: Forestil dig hvor mange ressourcer Microsoft bruger på at sikre at gamle binaries fra sidste årtusind stadig kan køre, og hvor meget cruft (inkl. sikkerhedsrisici) det trækker med i systemet?

Præcist pointen bag mit retoriske spørgsmål og bedre formuleret. Bagudkompatibilitet er en major sikkerhedsrisiko, eller måske mere præcist, sikkerhedsfaktor, i henhold til vedligeholdelses problematik?

Må jeg ikke lige tillade mig at nævne at når Pingsvinet #0 nævner de "Gamle versioner i Programhåndtering", så handler det om at man endnu ikke grundigt har testet. Det er jo klart nok ikke optimalt.

Det kan ikke nytte noget at en "spade" ikke kaldes for en "spade". Forklaringerne er overvejene økonomiske. Det er de næsten altid. Derfor bidrag til udviklerne har du evnen og du stoler på intentionen. Det er Open Source mere end blot al det her licens halløj.

Ja, det er rigtigt, og mit spørgsmål var heller ikke ment som brok :) Og med "risiko" tænkte jeg også på dette "afhængigheds-helvede", ikke så meget på virus. Så næste gang vil jeg gå efter "leaf"-pakker :) Tak for jeres tips.

#3
Det ville faktisk være rart med et værktøj der kunne bygge en statisk linket pakke ud fra et normalt dynanisk linket program. Det ville gøre det muligt i mange tilfælde at benytte ældre eller nyere version af et program uden at rende ind i "dependency hell".

Så lige at det er ret let at lave sin egen komplette app. Ikke statisk linket, men lige så brugbart. En 32 bit pakke kan så også køre på 64 bit, uden bøvl.

http://appimage.org/

Laver man dem selv, er der vel ingen "snavs" inden i.