Hur ofta installerar ni från source (tar-filer)?

Permalänk
Medlem

Hur ofta installerar ni från source (tar-filer)?

Tänkte bara fråga av ren nyfikenhet, hur ofta ni installerar program eller spel från source?

Finns det några fördelar med detta? Jag antar att man alltid kan ha den senaste versionen av programmet om man installerar från source?

Hur installerar ni source-filer? Finns det bara en metod eller flera?

Ett påstående: "Tar" på "Linux" är som "Exe" på "Windows? Stämmer detta?

Skiljer sig installationsmetoden mellan olika distributioner?

Många frågor nu.

Tack på för hand

MVH
Nyfikenpålinux!

Permalänk
Hedersmedlem
Skrivet av FullMoon:

Ett påstående: "Tar" på "Linux" är som "Exe" på "Windows? Stämmer detta?

Nej, de är inte exekverbara filer utan paket av andra filer. Som (okomprimerade) zip-filer. De kan även vara komprimerade men heter då vanligtvis .tar.gz, .tar.bz2 eller liknande.

Skrivet av FullMoon:

Skiljer sig installationsmetoden mellan olika distributioner?

Typiskt inte.

Permalänk
Hedersmedlem

Kör man en binär distribution (en distribution som tillhandahåller färdigkompilerade paket, vilket idag innefattar de mest använda) så lär det mer eller mindre aldrig behöva hända att man kompilerar eget (installerar från källkod som man själv bygger lokalt), men ibland kanske man vill.

För att komma med ett eget konkret mätvärde (använder Debian): de allra, allra, allra flesta program jag har installerade kommer direkt genom Debians programbank (> 2000 paket med alla beroenden). Ett fåtal andra installeras genom samma system, men från andra programbanker (Opera, Google Chrome, samt vissa paket från deb-multimedia).

Det enda större program som jag kompilerar själv heter Root. Det finns som en del i Debian, men åtminstone tidigare så var paketeringen inte i så bra skick, och jag vill kunna ha koll på vilka bibliotek och versioner som används, och detta gärna över flera datorer med olika distributioner, så därför sköter jag det själv. Detta kan komma att ändras vid en ny analys av hur programmet i sig samt den centrala paketeringen i distributionen sköts (det var några år sedan jag tittade på den biten senast; tittar jag i changelogen på Debians paketsida så verkar det ha bättrat sig). Ett tag kompilerade jag Audacious själv för att versionen i Debian släpade efter en del i samband med ett versionsbyte för ett sidobibliotek, och det hände mycket i utvecklingen av Audacious just då, men paketeringen kom sedermera ifatt. Utöver detta så har jag vid enstaka tillfällen kompilerat andra projekt för att kunna undersöka och fixa buggar för att skicka patchar till uppströms/Debian.

Ett fåtal stängda program installeras utanför paketsystemet (Matlab och Mathematica). Dessa är färdigkompilerade. BankID också, när jag tänker efter.

Fristående spel jag installerar är generellt stängda och kommer också färdigkompilerade. De är ofta paketerade i .deb-filer och hanteras av paketsystemet, dock. Några få kommer packade som .tar.gz eller liknande, men de behöver liksom ovanstående kategori inte kompileras, utan generellt bara packas upp på rätt plats, eller så körs de som ett shellscript som sköter detta åt en.

För att upprepa inledningen: som en användare av en binär distribution så "behöver" man i praktiken egentligen aldrig kompilera något, om man inte explicit vill. I vissa andra distributioner så kompilerar man egentligen allt själv, men ofta med någon sorts central automatisering som hjälper till med att sköta beroenden (sans Slackware).

Permalänk
Medlem

"Exe" i Linux kan man väl jämföra med sh, eller inget filformat angett alls. Jag brukar köra på det senare, då är det bara att göra så filen har en kod så den kan köras och göra den exekverbar. Sedan för att köra detta så skriver man in i terminal ./vadnufilenheter, eller sh vadnufilenheter.

Permalänk
Medlem

Formatet för binära körbara filer är "elf" i linux. Linux använder inte filändelsen för att avgöra filtypen. En eventuell filändelse är till för att ange filtypen och/eller version för användaren.
Jag kompilerar själv något c:a 1 gång per år.

Permalänk
Hedersmedlem

Fyller på med lite mer information.

Skrivet av FullMoon:

Finns det några fördelar med detta? Jag antar att man alltid kan ha den senaste versionen av programmet om man installerar från source?

Anledningar till att kompilera eget kan vara bland annat:

  • Programmet finns inte färdigkompilerat till arkitekturen/distributionen.

  • De växlar som distributionen har kompilerat paketet med motsvarar inte de du vill ha; exempelvis kan något saknas, eller så aktiverar distributionen fler saker än du av någon anledning önskar.

  • Du vill ändra i koden själv och se på resultatet, exempelvis för att hjälpa till med utvecklingen av programmet.

En anledning till att många vill undvika att kompilera själv är att det kan ta ordentligt med tid för stora/många paket. Om man inte kan använda automatisk beroendehantering så kan det också kräva att man sätter sig in i vilka sidobibliotek man behöver för att all önskvärd funktionalitet ska aktiveras, och man kan behöva kompilera dessa bibliotek, som i sin tur kan bero på ytterligare bibliotek, och plötsligt så flyger livet förbi utan att man har tid att lukta på blommorna.

Skrivet av FullMoon:

Hur installerar ni source-filer? Finns det bara en metod eller flera?

Källkoden distribueras traditionellt genom just ett packat tar-arkiv som redan nämnts, eller vanligare och vanligare genom att den klonas direkt från ett versionshanteringssystem (ofta via tjänster som Github, Bitbucket, Google Code, etc.).

Därefter konfigureras miljön genom ett medföljande konfigurationsskript. Vanligen är det bara att köra detta skript som kontrollerar att rätt bibliotek finns installerade, etc., men man kan även ge det olika växlar som kan påverka programmets funktion på olika sätt (lite som "klickandet" i ett installationsprogram i Windows, men oftast mer flexibelt).

När detta är klart så kompileras programmet, och därefter kan det (valbart) flyttas till systemets centrala kataloger för lokalt kompilerade program (tänk "C:\Program files", fast annorlunda, då ett program generellt lägger innehåll i multipla kataloger). Man kan även låta programmet ligga kvar i katalogen där det kompilerats och köra det därifrån, eller välja alternativa målkataloger om det finns anledning till detta (man kanske inte har rättigheter att skriva till centrala kataloger, eller man vill lägga programmet i sin hemkatalog för att det ska följa med oavsett vilken terminal man råkar sitta vid för tillfället).

Använder man en binär distribution kanske det kan vara fördelaktigt att själv skapa ett installationspaket under processen snarare än att installera programmet "bakom ryggen" på pakethanteringssystemet. Hur detta går till skiljer sig bland annat beroende på paketformat.

Skrivet av FullMoon:

Ett påstående: "Tar" på "Linux" är som "Exe" på "Windows? Stämmer detta?

Inte ens nära, som nämnts ovan . Ifall man hämtar hem källkod för att kompilera något själv i Windows så kan även den ofta vara i .tar.gz-format.

Om du menar .exe-filer så som `notepad.exe`, dvs en kompilerad binär för att köra ett program, så är ELF som nämndes ovan en analog, men filer heter inte ".elf", och detta är inget som en "vanlig" användare behöver bry sig om.

Om du menar .exe-filer så som `install_firefox.exe`, dvs ett installationsprogram, så är motsvarigheterna i stället exempelvis .deb för Debianbaserade system eller .rpm för Red Hat-baserade system. Dessa format är generellt bra mycket "smartare" än en .exe-installationsfil är i Windows; Wikipedia har mer information.

Vanligen så hanterar man inte sådana installationsprogram manuellt, utan man låter en pakethanterare göra det. Man säger snarare bara "installera LibreOffice, tack", så hämtar pakethanteraren en uppdaterad version av LibreOffice från distributionen, konfigurerar och installerar den, och ser sedan till att hålla den uppdaterad utan att man manuellt ska behöva spana på dess hemsida efter nya versioner med exempelvis säkerhets/buggfixar. Att hålla koll på ett program på det sättet vore ineffektivt; att hålla koll på 100 program vore praktiskt ogörbart.

Permalänk
Medlem
Skrivet av phz:

Information.

phz - Tack för ett väldigt välformulerat svar. Sjukt bra.

Trodde Linux geeks gillade kompilera program :P... Ja, du ser vilka fördomar man kan ha.

De senaste versionerna av ett program finns alltså oftast att installera som .deb, .rpm eller .sh fil?
Låter ju rätt simpelt.

Funderar nämligen att börja dual-boota Windows 8 och Linux Mint. Vill köra Linux som primärt OS.
Lite off-topic kanske. Men finns det någon bra guide i hur man dual-bootar dessa OS? Windows 8 är väl låst i Bios/Uefi om jag förstod rätt? Man måste låsa upp något om man vill dual-boota.

Permalänk
Hedersmedlem
Skrivet av FullMoon:

phz - Tack för ett väldigt välformulerat svar. Sjukt bra.

Trodde Linux geeks gillade kompilera program :P... Ja, du ser vilka fördomar man kan ha.

De senaste versionerna av ett program finns alltså oftast att installera som .deb, .rpm eller .sh fil?
Låter ju rätt simpelt.

Det är simplare än så: det är ytterst sällan jag manuellt installerar ett .deb-paket. Programdistribution är generellt ett fundamentalt annorlunda koncept än i Windows.

Eftersom mer eller mindre alla basprogram som används är fri programvara med öppen källkod så kan distributionerna själva kontrollera, kompilera och distribuera koden. Om det släpps en ny version av Firefox så kommer jag inte leta upp dess hemsida, ladda hem en .deb-fil och installera den; distributionen kommer centralt importera denna nya version, kompilera och paketera den, och sedan när jag väljer att uppdatera mitt system så kommer min dator fråga i mitt fall Debians servrar: "hallå där, finns det något nytt att hämta?", och Debian svarar: "jajamen, exempelvis Firefox, här får du!", och så installeras det automatiskt, tillsammans med alla andra uppdateringar av program och bibliotek som sköts på samma sätt.

Vissa distributioner väljer att även inkludera stängd programvara som Skype, Spotify, Steam, etc., på samma sätt; skillnaden är att distributionen då inte kan se koden bakom och därmed inte kontrollera varken säkerhet eller kvalitet eller direkt fixa buggar. Sådana projekt erbjuder ibland även egna programbanker (även om distributionen i sig inte gör det) som sköter denna kommunikation samtidigt som resten av systemet, och det finns även många privatpersoner som erbjuder liknande tjänster för produkter som inte har en egen sådan programbank.

Ett vanligt (kanske det vanligaste) problem som tidigare Windowsanvändare brakar in i när de installerar en Linuxdistribution är att de direkt ger sig ut och jagar efter "drivrutiner" och program från respektive tillverkares hemsida, när "drivrutiner" i själva verket generellt är en del av Linux i sig, och programinstallation med enormt mycket större smidighet sköts genom officiella programbanker. Det kommer ofta som en gigantisk överraskning att "Windowssättet" inte är synonymt med något sorts universellt sätt att sköta en dator, vilket snabbt yttrar sig i frustration på olika forum när det visar sig att man inte "kan allt", trots allt (troligen allra främst från de som ligger på "SweClockersnivån" i sitt Windowsanvändande, dvs lite mer insatt än "vanligt folk").

Permalänk
Medlem
Skrivet av FullMoon:

phz - Tack för ett väldigt välformulerat svar. Sjukt bra.

Trodde Linux geeks gillade kompilera program :P... Ja, du ser vilka fördomar man kan ha.

De senaste versionerna av ett program finns alltså oftast att installera som .deb, .rpm eller .sh fil?
Låter ju rätt simpelt.

Funderar nämligen att börja dual-boota Windows 8 och Linux Mint. Vill köra Linux som primärt OS.
Lite off-topic kanske. Men finns det någon bra guide i hur man dual-bootar dessa OS? Windows 8 är väl låst i Bios/Uefi om jag förstod rätt? Man måste låsa upp något om man vill dual-boota.

Nä, oftast gillar inte "Linux geeks" att kompilera själv. Det tar bara ihjäl onödigt mycket tid att kompilera när det finns en pakethanterare som har ett färdigkompilerat paket åt en. Varför ska man ta den krångliga vägen när man kan göra det simpelt? Linux går ut på KISS-principen.

Det som jag kommer på som man kanske måste låsa upp är väl Secure Boot. Det är bara att avaktivera i BIOS/UEFI. Här finns en guide som ser fin ut: http://itsfoss.com/guide-install-linux-mint-16-dual-boot-wind...

Permalänk
Entusiast
Skrivet av oTiuZ:

Nä, oftast gillar inte "Linux geeks" att kompilera själv. Det tar bara ihjäl onödigt mycket tid att kompilera när det finns en pakethanterare som har ett färdigkompilerat paket åt en. Varför ska man ta den krångliga vägen när man kan göra det simpelt? Linux går ut på KISS-principen.

Det som jag kommer på som man kanske måste låsa upp är väl Secure Boot. Det är bara att avaktivera i BIOS/UEFI. Här finns en guide som ser fin ut: http://itsfoss.com/guide-install-linux-mint-16-dual-boot-wind...

Uppdatera er KISS-länk till: http://en.wikipedia.org/wiki/KISS_principle
Verkar som om ni klistrat in mer text än tänk där

Permalänk
Medlem
Skrivet av phz:

Eftersom mer eller mindre alla basprogram som används är fri programvara med öppen källkod så kan distributionerna själva kontrollera, kompilera och distribuera koden. Om det släpps en ny version av Firefox så kommer jag inte leta upp dess hemsida, ladda hem en .deb-fil och installera den; distributionen kommer centralt importera denna nya version, kompilera och paketera den, och sedan när jag väljer att uppdatera mitt system så kommer min dator fråga i mitt fall Debians servrar: "hallå där, finns det något nytt att hämta?", och Debian svarar: "jajamen, exempelvis Firefox, här får du!", och så installeras det automatiskt, tillsammans med alla andra uppdateringar av program och bibliotek som sköts på samma sätt.

Automatik - det gillar vi
Om man mot förmodan inte har tillgång till internet men vill installera ett program, låt oss säga, rythmbox; då kanske det bästa sättet är att använda sig av en .deb fil?

En fråga till:
Skiljer sig Ubuntus .deb filer, vs debians .deb filer?
Vissa sidor har exempelvis; "Download for Debian" och en separat för Ubuntu; "Download for Ubuntu". Men båda är .deb-filer?
Om jag ladda ner en .deb fil från Ubuntus repository, kan jag installera den i Debian?

Permalänk
Medlem
Skrivet av oTiuZ:

Nä, oftast gillar inte "Linux geeks" att kompilera själv. Det tar bara ihjäl onödigt mycket tid att kompilera när det finns en pakethanterare som har ett färdigkompilerat paket åt en. Varför ska man ta den krångliga vägen när man kan göra det simpelt? Linux går ut på KISS-principen.

Det som jag kommer på som man kanske måste låsa upp är väl Secure Boot. Det är bara att avaktivera i BIOS/UEFI. Här finns en guide som ser fin ut: http://itsfoss.com/guide-install-linux-mint-16-dual-boot-wind...

Skrivet av SysGhost:

Uppdatera er KISS-länk till: http://en.wikipedia.org/wiki/KISS_principle
Verkar som om ni klistrat in mer text än tänk där

Tack

Permalänk
Medlem
Skrivet av SysGhost:

Uppdatera er KISS-länk till: http://en.wikipedia.org/wiki/KISS_principle
Verkar som om ni klistrat in mer text än tänk där

Oj, hoppsan ^^

Permalänk
Hedersmedlem
Skrivet av FullMoon:

Om man mot förmodan inte har tillgång till internet men vill installera ett program, låt oss säga, rythmbox; då kanske det bästa sättet är att använda sig av en .deb fil?

Så kan man göra, men det brukar inte dröja särskilt länge innan frustrationen visar sig. Paket kräver ofta att en mängd andra paket också installeras (eller redan finns i systemet), så det gäller att man laddar ned även dem i förväg. Är man uppkopplad hanteras sådant automatiskt. Det går dock att få till exempel synaptic att generera ett skript som laddar ned de paket som behövs baserat på vad man redan har i systemet.

Permalänk
Medlem
Skrivet av Elgot:

Så kan man göra, men det brukar inte dröja särskilt länge innan frustrationen visar sig. Paket kräver ofta att en mängd andra paket också installeras (eller redan finns i systemet), så det gäller att man laddar ned även dem i förväg. Är man uppkopplad hanteras sådant automatiskt. Det går dock att få till exempel synaptic att generera ett skript som laddar ned de paket som behövs baserat på vad man redan har i systemet.

Så med andra ord är Linux rätt dåligt på offline-burkar?

Permalänk
Hedersmedlem
Skrivet av FullMoon:

Så med andra ord är Linux rätt dåligt på offline-burkar?

Det är kanske att dra det lite långt, men det kräver lite mera planering.

Permalänk
Medlem
Skrivet av FullMoon:

Så med andra ord är Linux rätt dåligt på offline-burkar?

Nej, inte mer än något annat operativsystem Väldigt ofta finns CD/DVD-avbildningar med en massa programvara att tillgå för distributionen. Pakethanterare är enligt mig en väldigt stor fördel kontra Windows.

Permalänk
Medlem
Skrivet av Elgot:

Det är kanske att dra det lite långt, men det kräver lite mera planering.

Skrivet av jagardaniel:

Nej, inte mer än något annat operativsystem Väldigt ofta finns CD/DVD-avbildningar med en massa programvara att tillgå för distributionen. Pakethanterare är enligt mig en väldigt stor fördel kontra Windows.

Alright, men då förstår jag

Permalänk
Hedersmedlem
Skrivet av jagardaniel:

Pakethanterare är enligt mig en väldigt stor fördel kontra Windows.

Ian Murdock, som grundade just Debian en gång i tiden, har gått så långt som att hävda att det är det enskilt största framsteget som Linuxdistributioner har bidragit med till branschen. Även om det finns många kandidater till en sådan titel så är det i sanning vansinnigt smidigt jämfört med alternativen.

Permalänk
Medlem

Eftersom jag själv programmerar lite i C så kompilerar jag mina egna program från källkod förstås. Man lär sig ganska mycket om hur det fungerar genom att testa att programmera själv. Det är också bra att testa installera och avinstallera andras program från källkod någon gång för att förstå hur det funkar.

Men när det gäller andras programvaror så kör jag via distributionens paketfiler i första hand eftersom det är smidigast. Jag kör Arch Linux och där finns också AUR som betyder Arch User Repository. Det är användare som själva skickar upp programvara som script för att skapa binära paket från källkod. Dessa ligger som tar-filer som man packar upp och sedan kör man kommandot "makepkg -s" i den uppackade filmappen och då kompileras paketet som man sedan kan installera. Då får man med det i pakethanteringssystemet och det blir lättare att hantera beroenden och sådant. Jag installerar program från AUR ganska ofta. Det är ytterst sällan som det jag vill installera varken finns i Arch Linux paketförråd eller i AUR. Men om så vore skulle jag nog försöka lägga upp det på AUR själv, men det är något jag ännu inte gjort.

Det finns också ett tredje sätt som jag använder litegrann och det är att man kan lägga till externa paketförråd för binära paket i pakethanteringssystemet. Exempelvis använder jag ett sådant för programmen som krävs för ZFS filsystem för att själv slippa kompilera om dessa varje gång en ny kärna installeras. Nackdelen är att då detta sköts av någon tredjepart så blir man beroende av att personen håller paketen ständigt uppdaterade men just för ZFS har det funkat hyfsat bra. Om det inte funkar bra så tröttnar man på dessa förråd och kör själv via AUR istället. Nu finns även dessa program oftast i AUR också så det är ingen katastrof om tredjepartsrepositoryt inte är uppdaterat.

Edit: Glömde nämna att i Arch Linux finns alla binära paket i paketförråden även tillgängliga som källkodspaket packade på samma sätt som källkodspaketen i AUR. Det systemet heter ABS (Arch Build System). Då kan man uppdatera källkodsträdet och sedan manuellt skapa samma paket som de binära paketen i paketförråden. Ja men vad ska det vara bra för då kan man undra? Tja om man vill ändra i källkoden (exempelvis kan det finnas optioner man ställer in innan man kompilerar en viss programvara för att få extra funktionalitet) eller om man vill kompilera om paketet med optimeringar för den egna processortypen. Så AUR och ABS fungerar på ungefär samma sätt.

Sammantaget så tycker jag det är bättre att skapa ett binärt paket anpassat för den pakethanterare man använder från källkoden än att gå bakom ryggen på pakethanteraren. Sedan installerar man det binära paketet.

Permalänk
Medlem
Skrivet av ronnylov:

Eftersom jag själv programmerar lite i C så kompilerar jag mina egna program från källkod förstås. Man lär sig ganska mycket om hur det fungerar genom att testa att programmera själv. Det är också bra att testa installera och avinstallera andras program från källkod någon gång för att förstå hur det funkar.

Men när det gäller andras programvaror så kör jag via distributionens paketfiler i första hand eftersom det är smidigast. Jag kör Arch Linux och där finns också AUR som betyder Arch User Repository. Det är användare som själva skickar upp programvara som script för att skapa binära paket från källkod. Dessa ligger som tar-filer som man packar upp och sedan kör man kommandot "makepkg -s" i den uppackade filmappen och då kompileras paketet som man sedan kan installera. Då får man med det i pakethanteringssystemet och det blir lättare att hantera beroenden och sådant. Jag installerar program från AUR ganska ofta. Det är ytterst sällan som det jag vill installera varken finns i Arch Linux paketförråd eller i AUR. Men om så vore skulle jag nog försöka lägga upp det på AUR själv, men det är något jag ännu inte gjort.

Det finns också ett tredje sätt som jag använder litegrann och det är att man kan lägga till externa paketförråd för binära paket i pakethanteringssystemet. Exempelvis använder jag ett sådant för programmen som krävs för ZFS filsystem för att själv slippa kompilera om dessa varje gång en ny kärna installeras. Nackdelen är att då detta sköts av någon tredjepart så blir man beroende av att personen håller paketen ständigt uppdaterade men just för ZFS har det funkat hyfsat bra. Om det inte funkar bra så tröttnar man på dessa förråd och kör själv via AUR istället. Nu finns även dessa program oftast i AUR också så det är ingen katastrof om tredjepartsrepositoryt inte är uppdaterat.

Edit: Glömde nämna att i Arch Linux finns alla binära paket i paketförråden även tillgängliga som källkodspaket packade på samma sätt som källkodspaketen i AUR. Det systemet heter ABS (Arch Build System). Då kan man uppdatera källkodsträdet och sedan manuellt skapa samma paket som de binära paketen i paketförråden. Ja men vad ska det vara bra för då kan man undra? Tja om man vill ändra i källkoden (exempelvis kan det finnas optioner man ställer in innan man kompilerar en viss programvara för att få extra funktionalitet) eller om man vill kompilera om paketet med optimeringar för den egna processortypen. Så AUR och ABS fungerar på ungefär samma sätt.

Sammantaget så tycker jag det är bättre att skapa ett binärt paket anpassat för den pakethanterare man använder från källkoden än att gå bakom ryggen på pakethanteraren. Sedan installerar man det binära paketet.

Man lär sig ganska mycket här på Sweclockers :). Tack!
Ska testa Arch sen när jag fått mer Linux-experience