Varför är det bättre att kompilera än att installera från förvaren

I den här lilla guiden ska jag förklara (och lära dig) varför det är bättre att du sammanställer ett program (säg Firefox, Vlc, etc) från dess källkod, än att ladda ner det (från The Software Center, Yumex, Pacman, etc ) och installera.

Först går vi med teorin:

Vad är "kompilera"?

Kompilering omvandlar källkoden (kod skriven på ett visst programmeringsspråk, säg C, C ++, etc.) till ett körbart program för dess användning genom att använda processorn för att konvertera språket som används för att generera koden till binär och samlare. Det kallas också ofta förpackning.

Varför är det bättre att "kompilera"?

Först måste du veta följande för att förstå varför. Sagt på ett "grovt" sätt (enkelt, inte särskilt professionellt, etc), har varje lopp (Pentium, Core, Atom, etc) och dess art (Intel, AMD, ARM, etc.) processorer instruktioner (programvara skriven i samlare som bearbetar koden) för sin modell (Core i7, Core i5, Atom x2, Phantom x8, Arm, etc.) och har också allmänna instruktioner som alla i sitt slag har.

När du laddar ner från förvaren via Software Center / apt-get / Yumex / Yum / Pacman / etc, sägs ett program som installeras automatiskt vara det här förkompilerad för drift på alla möjliga processorer (Intel och Amd). Eftersom det är ett förkompilerat program går de instruktioner som är typiska för den specifika processormodellen förlorade (tänk att om ett program som Firefox eller Chrome, som har mer än 7 eller 8 miljoner rader kod, var de tvungna att lägga alla specifika instruktioner för varje processor på marknaden, skulle mängden kod vara så stor att det programmet inte längre skulle vara effektivt) och lämna inget mer än de generella av dess skaparvarumärke (Intel, Amd, Arm).

När du laddar ner, dekomprimerar och kompilerar källkoden för ett program själv, kompileras det med de specifika instruktionerna för TU processor, (vilket inte betyder att det inte fungerar på en maskin med en annan, bara att den kommer att optimeras specifikt och enbart för din processor), därmed släppa loss och släppa all den kraft som din processor kan ge tack vare dess specifika instruktioner.

I mer tekniska detaljer är dessa specifika instruktioner nära kopplade till det som kallas chipsetet på ditt moderkort, vilket är den stora huvudvärken för oss som har Intel när vi vill uppgradera processorn och moderkortet.

Du skulle bli förvånad över den kraft som din amd atom x2 eller du Intel Core inuti, Kärna 2 Duo, i3, etc från din gamla dator. Nu förstår du varför det är mycket prat i Linux-världen om att kompilera den berömda Kärnan (hjärtat i varje operativsystem)? Tänk om du kompilerar ett helt system (grafisk miljö (Gnome, Kde, etc), Kernel, vanliga program (Firefox, Vlc, Chrome, Wine, etc.) speciellt för din dator) all hastighet och optimeringsnivå du skulle ha.

Denna sammanställningsprincip för att erhålla en kod som är optimerad speciellt för din maskin är den som används av distros som Gentoo och derivat (som jag inte kommer att prata om nu, jag använder Fedora minimal med sammanställning av Gnome 3, kärnan och andra program) där systemet, dina uppdateringar och dina program alltid sammanställs.

Nackdelar med sammanställning:

Jag har redan förklarat alla fördelar, men som allt i universum har det en emot.

I sammanställningsfallet är de;

  • Den tid som behövs för detta (Firefox med en i7 4790K (utan överklocka eftersom jag är väldigt dålig med spänningar) tar 3 minuter, Gnome Shell (baren inget mer) med Gnome-Control-Center tog mig cirka 2 minuter, båda sammanställdes på samma tid i Fedora. Men på en maskin med en mindre kraftfull processor kan den här tiden vara oproportionerligt lång).
  • Processorn använder 100% av sin kraft med alla sina kärnor maximalt, så förbrukning och värme skjuter i höjden (ta hänsyn till detta om du har överklockning eller om det särskilt är en bärbar dator), så det är bekvämt att du förbereder en kompis eller en kaffe för tillfället.
  • Du kanske saknar ett bibliotek (verktyg) som använder ett program så att det inte blir fel i kompileringen. I allmänhet har alla distros paket eller uppsättningar av dem för att undvika detta (de är packade med olika bibliotek och andra saker som gör att kärnan kan kommunicera som den ska med processorn under processen).

Hur kan jag sammanställa?

För Debian (Ubuntu, Mint, Elementary, etc är de alla derivat av detta så följ detta

Här talar jag om att kompilera ett program för normal användning, inte en kärna.

aptitude installera build-essential dh-make devscripts fakeroot debhelper debian-policy ccache dh-autoreconf autotools-dev build-dep ardor

Jag lägger debian-policy, men om din distro inte är Debian och det ger dig ett fel att inget sådant paket finns, ignorerar du det bara. Jag måste klargöra att jag inte har använt dessa system på länge, så om ett paket inte längre finns i förvaret, gör inte något problem.

För Fedora:

sudo yum -y install kärnhuvuden
kärnutveckling
sudo yum gruppinstallera "Utvecklingsverktyg"
sudo yum groupinstall "Utvecklingsbibliotek"

Här måste jag be om ursäkt för dem som använder Arch (jag känner inte distro väl) och OpenSuse, eftersom jag inte känner till dessa distributioner eller respektive paket för att utföra en korrekt sammanställning (och jag har inte bekräftat vad som finns i nätverket, så att för de två vet jag inte om de fungerar).

Nu när du har alla nödvändiga krav behöver du bara ladda ner källkoden för programmet du vill kompilera, beroende på tillägget du packar upp det med terminalen (oroa dig inte, jag lämnar kommandona) och när du går till mappen (alltid med terminalen) gör du samma:

Om du har möjlighet att konfigurera dig själv för att välja komponenter och andra:

./configure

Sedan skriver du:

make

Och slutligen för att installera programmet på din linux:

make install

Allt detta alltid med root (su i Fedora, sudo su i Ubuntu och dess derivat (Mint, Elementary Os, etc)

Kommandon att packa upp med terminalen (filen packas upp i en mapp där filen finns):

.Tar-filer (tjära) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Pack | tar cvf file.tar / file / * Packa upp | tar xvf file.tar Visa innehåll | tar tvf file.tar
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .tar.gz - .tar.z - .tgz (tjära med gzip ) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Pack och zip | tar czvf file.tar.gz / file / Packa upp och packa upp | tar xzvf file.tar.gz Visa innehåll (extraheras inte) | tar tzvf-fil.tar.gz
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .gz (gzip) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Komprimera | gzip -q-fil (Filen komprimerar och byter namn till "file.gz") Unzip | gzip -d file.gz (Filen packar upp den och lämnar den som "fil" Obs! gzip komprimerar endast filer, inte kataloger
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .bz2 (bzip2) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Komprimera | bzip2-fil | bunzip2-fil (Filen komprimerar och byter namn på den till "file.bz2") Unzip | bzip2 -d file.bz2 | bunzip2 file.bz2 (Filen packar upp den och lämnar den som "fil") Obs! bzip2 komprimerar bara filer, inte kataloger
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .tar.bz2 (tjära med bzip2) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Komprimera | tar -c-filer | bzip2> file.tar.bz2 Unzip | bzip2 -dc file.tar.bz2 | tjära -xv | tar jvxf file.tar.bz2 (senaste versioner av tar) Visa innehåll | bzip2 -dc file.tar.bz2 | tjära -tv
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .zip (zip) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Komprimera | zip file.zip / mayo / arkiv Unzip | unzip file.zip Visa innehåll | packa upp -v file.zip
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .rar (rar) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Komprimera | rar -a file.rar / may / archives Unzip | rar -x file.rar Visa innehåll | rar -v file.rar | rar -l file.rar

Och det är allt. Hälsningar från Buenos Aires, Argentina. God jul och nyår! :).


Innehållet i artikeln följer våra principer om redaktionell etik. Klicka på för att rapportera ett fel här.

67 kommentarer, lämna din

Lämna din kommentar

Din e-postadress kommer inte att publiceras.

*

*

  1. Ansvarig för uppgifterna: Miguel Ángel Gatón
  2. Syftet med uppgifterna: Kontrollera skräppost, kommentarhantering.
  3. Legitimering: Ditt samtycke
  4. Kommunikation av uppgifterna: Uppgifterna kommer inte att kommuniceras till tredje part förutom enligt laglig skyldighet.
  5. Datalagring: databas värd för Occentus Networks (EU)
  6. Rättigheter: När som helst kan du begränsa, återställa och radera din information.

  1.   Gonzalo sade

    Problemet med att kompilera är att det inte alltid fungerar första gången och är mer tråkigt

    1.    cristian sade

      Problemet med att kompilera är att om du inte har en gammal och begränsad dator kommer förbättringarna inte att märkas ... ja kanske på en dator med intensiv användning är det ett alternativ, men för de flesta användare är det bara en tråkig process.

      1.    Daniel sade

        Jag tror att det är kärnan i saken. Är prestandaförbättringen som kommer att märkas när du kompilerar paketen så viktigt att det tar tid och besvär med denna uppgift i bakgrunden?

      2.    joaco sade

        Detsamma om du har en i7-kompilering är det bekvämt, för det är snabbare och jag beräknar att det fungerar något bättre. Nu med en dator med Intel Atom är det inte bekvämt, såvida du inte behöver den extra kraften som kompileringen ger, men det kan ta timmar att kompilera ett program med en mindre kraftfull processor.

    2.    Avrah sade

      Jag håller helt med, det har hänt mig att kompilera och ta reda på efter ett tag att du saknar ett bibliotek, spåra det och måste möta processen igen ... Det är sällsynt att allt fungerar vid första försöket ... xD

  2.   Ferge sade

    Mycket intressant!

    Om du sammanställer ett program, hur fungerar uppdateringarna efteråt? Är de automatiska eller måste vi vara medvetna om huruvida en ny version har kommit ut?

    1.    Anthony Fields sade

      Du måste uppdatera den manuellt, det vill säga att sammanställa den senaste versionen som är en annan, låt oss säga "nackdel", för vilken det också gör något tråkigt

    2.    jlbaena sade

      Eftersom uppdateringar inte existerar, eliminerar faktiskt Linux-distributioner och deras olika sätt att förpacka programvaran och motsvarande pakethanterare besväret med att kompilera om för varje ny uppdatering (och lösa beroenden).

      Hälsningar.

    3.    joaco sade

      Om du kompilerar det genom att ladda ner källkoden från vilken sida som helst måste du göra det manuellt och lära dig hur du installerar det eftersom inte alla är installerade samma.
      Nu, om du har Gentoo eller någon distro med portar, gör du det nästan automatiskt från förvaren.

    4.    Fermín sade

      I Gentoo tar din pakethanterare, Portage, hand om uppdateringar och beroenden; Jag vet inte om andra distributioner. Naturligtvis innebär varje uppdatering uppenbarligen omkompilering.

  3.   tanrax sade

    Det var en tid då jag sammanställde allt jag kunde. Sedan blev jag trött, särskilt på grund av den tid jag fick ägna mig åt att maskinen skulle fungera (45 min för kärnan, 10 min för krom ...) och på grund av den tid jag spenderade på att lösa problem som uppstod i farten. Dessutom hittade jag personligen ingen prestationsökning, jag hade en känsla av att allt var detsamma. Av dessa skäl använder jag nu allt förkompilerat, allt är omedelbart och utan konflikter. Även om jag lärde mig mycket vid den tiden ville jag använda gentoo 🙂

  4.   emmanuel sade

    Till och med, och det är något jag har sett lite, kan det sammanställas från system som apt. Lägg till en build-flagga till apt-source och voila. Naturligtvis, innan det, installerar du nödvändiga paket för att utföra kompileringarna, annars fungerar det inte ... även om det är en mer direkt form av kompilering och det innebär färre steg, eftersom det bara är första gången det upptar installationen av paket och följande, de uppfyllda beroendena och paketet som sådant.

    Hälsningar.

    1.    joaco sade

      Den har apt-build-funktionalitet, även om jag tror att den inte kompilerar beroenden, utan installerar förkompilerade binärer.

  5.   xikufrancesc sade

    Från det första ögonblicket jag såg rubriken kunde jag inte låta bli att tänka samma sak, och efter att ha läst hela den utmärkta artikeln har jag tanken på att gå tusen gånger, Gentoo ... Gentoo, var är du?
    att kompilera är underbart, att kunna njuta av vissa funktioner och använda dem är ovärderligt, men tid och "nuvarande behov" är oförlåtliga, eftersom de inte gäller.
    Kanske behöver vi något i mitten, där varken bibliotek eller detaljer i versionändring kommer att slösa bort så mycket tid. Vi kommer att se vad som kommer att hända då, eller om vi verkligen tillämpar oss för att kompilera på själva aptiten, uprmi och zypper som vi redan har installerat.

  6.   anonym sade

    3 minuter Firefox! .... Menade du 30?

    Detta tog ett tag på min dator med en fx8350 på 4.5G, jag använder gentoo.
    $ genlop -t Firefox | svans -n3
    Lör 6 dec 20:00:00 2014 >>> www-client / firefox-34.0.5-r1
    sammanslagningstid: 16 minuter och 35 sekunder

    Dessa instruktioner som är specifika för varje processor kallas mnemonics och är fysiskt implementerade i mikroprocessorn, det är de som utgör maskinspråket, och kompilerar därför så att ett program kan köras på många typer av mikroprocessorer, om eller om de måste begränsas minsta mängd vanliga minnesstöd som stöds i alla dessa mikroprocessorer ... slösa verklig kapacitet hos de mest aktuella och kraftfulla mikroprocessorerna.
    Så här gör företag och binära distributionssystem för GNU / Linux.

    1.    Shyancore sade

      För mig med en Intel i7 4790K med 18 GB RAM har det tagit mig vad jag sa tidigare

      1.    anonym sade

        Jag förstår att det mikro du har är överlägset, men skillnaden är dyster, sanningen måste vara en savanna i den hastigheten. Kanske är det något som är relaterat till beroenden eller ANVÄNDNINGAR, som är desamma som konfigurationsalternativen när man kompilerar för hand.

      2.    Jhonny sade

        Liten detalj som du undanröjde med att säga 18 GB Ram förutom i7, inte alla har den maskinen, men du kan göra en benchmarking så att skillnaden märks, för teorin är trevlig men låt oss se om den kompenserar.

      3.    cristian sade

        En annan stor detalj, processorn är Intel, därför har den den bästa flytpunkten oberoende av modellen, en mycket relevant funktion för att utföra denna typ av process

    2.    ezekiel sade

      Det är sant att det är tråkigt att kompilera. Men du lär dig mycket genom att avstå från Makefiles, bibliotek etc. Det är något som är bra att göra även ett par gånger. Jag använder allt förkompilerat av samma anledning som Tanrax citerade.

      Hälsningar från Argentina!

  7.   Erick carvajal sade

    Problemet som jag har i allmänhet när jag försöker kompilera helt nya versionsprogram beror alltid på beroenden, ibland är det nödvändigt att sammanställa dem alla (för att komma till de senaste versionerna) och sedan fundera på att kunna kompilera vad du vill.

    PATH-problem och FLAGGAR är de saker som fortfarande hindrar mig från att vilja sammanställa allt (även om jag vanligtvis gör det som jag kan). Ett av verktygen som jag brukar konsultera för att sammanställa beroenden är följande webbplats - http://www.linuxfromscratch.org/ -

    #LinuxFromScratch är ett projekt som ger "steg-för-steg-instruktioner" för att sammanställa källkoden som du behöver använda i systemet .. (98% av vad jag har behövt för att sammanställa har jag uppnått genom att vägleda mig härifrån och gradvis inlärning).

    Som en pluspunkt tror jag att att kompilera ett system från 0 skulle vara intressant, särskilt för utvecklingsmiljöer eller servrar, bland annat som vi säger "är vanligtvis inte lika utbytbara" som en persondator där vi ständigt installerar och ändrar allt (det är min synvinkel) utöver det faktum att den minsta prestanda som uppnås i denna typ av användningsapplikationer är mycket viktig.

    Det här är punkter där mycket lite sägs idag och bara "forskarna" klarar sig, men det är intressant att ge sådana saker de självstudier de behöver så att vi varje dag hittar fler människor som bidrar med hjälp till de olika samhällen där de deltar och Inte bara Gnu / Linux förblir i tid på grund av den dåliga prestandan hos medarbetarna, att även om "detta har hittills fungerat" är det inte särskilt hälsosamt att bara ha slutanvändare.

  8.   Rabuda Eagle sade

    Tillåt mig ett litet tillskott. För att få de fördelar du exponerar här måste du konfigurera det välkända make.conf korrekt. Där anges processorfamiljen och kompileringsflaggor. På samma sätt kan du ange antalet kärnor som ska användas under kompilering. När du använder alla kärnor i din mikrofon reduceras sammanställningstiden drastiskt.

    hälsningar

  9.   Sebastian sade

    Mycket bra artikel. Jag skulle också ha velat ha ett exempel eller jag skulle vilja ha ett inlägg om hur man kompilerar i archlinux eller hur man använder AUR. Gott nytt år från Mendoza.

  10.   The Guillox sade

    För länge sedan ... Jag har alltid kompilerat kärnan, men det är väldigt tråkigt att behöva vänta 40 minuter: / hur som helst ... Jag har inte sammanställt någonting utom videodrivrutinerna på länge (endast för speciella konfigurationer).

  11.   Alexander sade

    Artikeln är väldigt intressant, men ingen herr, förpackning och sammanställning är inte detsamma;) ..

  12.   c4explosiv sade

    Mycket bra inlägg. Jag håller med att sammanställa vissa program, men ibland är det lite tråkigt så det tar maskinen att göra processen. Men förutom det lär man sig mycket, särskilt när bibliotek eller paket behövs.
    Jag tror att för Archlinux, för att kompilera behöver du följande paket: base-devel
    pacman -S basutveckling

  13.   råttdöd sade

    Informationen är mycket bra, men sanningen är att det inte är nödvändigt att sammanställa, om du är en standardanvändare och du bara vill att något ska fungera så här, rör inte ens det. Det är tråkigt att kompilera, alltid, jag säger alltid att du saknar ett bibliotek, du stöter på ett eller annat problem, säger till mig att kompilera minecraft-servern så att allt blir så bra som möjligt och jag tar dig tid .... förutom att varje gång en uppdatering eller patch eller vad som helst kommer ut, börja kompilera xd igen

    1.    kik1n sade

      Exakt, kompilering är för mycket specifika program som du behöver för optimal användning, för att kompilera allt, och som du säger, det finns alltid uppdateringar, oftast rullande release distros, är irriterande. Jag skulle bara rekommendera lts kärnor.

  14.   FedoraAnvändare sade

    Idag stöder nästan alla processorer som människor använder samma instruktioner, därför är det bara fördelaktigt att kompilera när det gäller kärnan och i ett system som en server, att, och uppenbarligen när det inte finns några förkompilerade paket, är allt annat slöseri med tid.

  15.   John Mere sade

    Bra bidrag, jag ska försöka se hur det går, hittills (nästan alltid) installerar jag från förvaren ...
    Liten observation: alternativet rar för kommandot är oskriptat och endast bunzip2 packas upp.

  16.   Santiago sade

    Det mesta jag kompilerade var en kärna för debian wheezy och det tog mig ungefär 2 timmar (jag har en AMD e450 1.6 GHz dual-core cpu) och det är just därför jag inte installerar gentoo, det är dags att kompilera och ladda ner hela systemet skulle ta mig ungefär 18 timmar, och att om jag inte har några problem, är det sant att det är bättre att sammanställa men för det mesta är den tid det tar för mycket och jag tycker att det inte är värt det. Du har en hastighetsuppgång men det är inte mycket och jag tror att det inte motiverar hela tiden som investerats. Även om jag en dag har en dator med en processor som är lika bra som din, försöker jag installera gentoo 😛

  17.   Vampier sade

    Människor:

    Utan flamintentioner eller något, slackers ser det som naturligt att kompilera, generera binär, installera det med relevant pakethanterare (som löser beroenden uppenbarligen, slapt-get, swaret, slackyd och / eller flera andra), med allt optimerat för vår team och som om ingenting, vilket är inget att skriva hem om eller kvantfysik.

    Att titta på en DVD utan att snubbla på en P3 750MHz med 192MB RAM är varken omöjligt eller svårt att uppnå över Slackware. Jag intygar att det är snabbare än att kompilera en Gentoo. Men det är inte detsamma, jag använder också Gentoo.

    Skillnaden mellan hackare och konsument är att konsumenten säger "Jag önskar att det skulle fungera på det sättet" och hackaren "Jag har en skruvmejsel och några minuter" - Rael Dornfest

  18.   pepenrike sade

    Finns det verkligen en märkbar förbättring av prestanda?
    Med en sista generationens i7 och 18 Gb ram, hur märker du skillnaden mellan kompilerade paket och binära filer?

    Jag har alltid hatat om lämpligheten av självkompilerande paket, men jag tror att det i dagens skrivbordsmiljö är mycket komplicerat att upprätthålla det, särskilt på grund av beroendets komplexitet, de kontinuerliga uppdateringarna och det enorma beroendet av icke-fri källor., som i fallet med egna drivrutiner, som utan tvekan påverkar prestanda mycket mer än någon aspekt som kan sammanställas ...

    hälsningar

    1.    Shyancore sade

      Med tanke på att Gnome 3 bara kompilerar det (jag kommer att säga namnen grovt eftersom namnen på paketen jag inte kommer ihåg): skalet (stapeln), gnome-control-center (komplett, med dess beroenden, etc), appleten för tiden och cirka 2 eller 3 beroenden för att skalet ska fungera. Självklart krävde skalet fler beroenden för att alla dess funktioner skulle fungera men det ledde mig till att bland annat kompilera GDM, jag fixade det genom att ändra det med GConf när skalet kompilerades.
      Nu när jag loggar in (via terminal) tar miljön mycket mindre tid att ladda än när den installerades förkompilerad. Att kasta en tid i luften på ett förkompilerat sätt tror jag att det tog cirka 3 eller 4 sekunder att ladda skalet (med cirka 5 där tapeten visas, jag förstod aldrig varför det tog så lång tid, det verkar för mig att det beror på föraren med GT 630) och sammanställs så fort jag angav lösenordet, X org startar och miljön laddas (med förspänning och förlänk gjorde jag dem mycket snabbare, det verkar för mig att det beror på att de passerade till cachen; https://www.google.com.ar/search?q=preload+y+prelink+fedora&ie=utf-8&oe=utf-8&gws_rd=cr&ei=iXaqVPykO4qYNpbTgdAP )

    2.    mario sade

      Det faktum att i7 har ss4 och ss3 instruktioner, som ignoreras av generiska builds från olika distros (debian builds för 486, ubuntu för 686) kan ge dig en uppfattning om när hårdvara slösas bort när du försöker spänna en 20 år gammal processor - kanske tack för att du stöder min gamla pentium mmx-. Om du behöver "proprietära drivrutiner" som du nämnde, ger kärnan möjlighet att ladda specifik firmware vid tidpunkten för sammanställning. Inga fler konstiga problem med xorg.

  19.   Fabian Alexis sade

    Tack för informationen, det är alltid bra att lära sig (eller lära sig om) (:

  20.   Xavier sade

    Debian gärna till Gentoo 🙂
    http://crysol.org/es/node/699

  21.   Yuan sex sade

    En annan nackdel är att sammanställningen per terminal är för användare som känner till eller redan har kunskap om Linux. Finns det ett grafiskt verktyg som inte hanterar sammanställning, installation och uppdatering av program utan grafiskt?

    1.    mario sade

      Beräkna linux gör det, det är en gentoo med grafiska verktyg redo att kompilera. I Phoronix rekommenderar de det vanligtvis.

  22.   José sade

    Jag är en Linux-användare, ibland när jag vill installera ett program från förvaret installeras de gamla versionerna av programmet, helt enkelt för att de nya inte är kompilerade för distro i fråga, jag tror att det är viktigt att veta hur man kompilerar, ännu mer när de används sällsynta distros.

  23.   joan sade

    Allt det står i inlägget är bra och jag tvivlar inte på att det är sant, men skillnaden i prestanda mellan att installera ett binärt paket och kompilera dig själv är omärklig för en användare.

    Och nackdelarna med att sammanställa är många och om de är tydligt märkbara för användaren. Därför går jag personligen för att sammanställa.

  24.   NauTiluS sade

    Där jag har märkt mest prestanda när jag kompilerar kärnan var det på en bärbar dator med en AMD 64-processor. Förändringen mellan fabrikskärnan och den kompilerade var brutal.

    Just nu har jag en fabrikskärna på mitt system, för som de säger mycket här, det var en tid då jag sammanställde nästan allt och jag blev trött.

    Just nu sammanställer jag bara några mycket viktiga program, som att använda en liten server eller att spela med emulatorer. För inte länge sedan gjorde jag ett inlägg om hur man kompilerar mame-versionen. Dessa program märker vanligtvis när du har det optimerat för ditt system.

    Jag behöver bara prova den gentoo distro och se hur föreställningen går.

  25.   NauTiluS sade

    Jag glömde att lägga till, till människor som tar lång tid att kompilera kärnan, mer än 30 minuter, det finns flera knep för att göra det på kortare tid.

    Ett av dessa knep är att, bara kompilera modulerna i din utrustning, högst, kanske högst 70 moduler är vad som visas för dig och om vi lägger till stöd för iptables med alla dess krav, tror jag att det skulle öka till 300 moduler. Kom igen, det är mycket bättre än att kompilera 3000 udda moduler, en siffra som för närvarande körs om kärnmodulerna sammanställs när de kommer från fabriken eller som de säger, vanilj.

    Programmet som hjälper dig att veta vilka moduler kärnan för närvarande känner igen i ditt system är "localmodconfig" eller genom att använda detta skript "streamline_config.pl" som finns i kärnkällkatalogen, i sökvägen "/ scripts / kconfig /»

    Självklart, se till att du har alla dina USB-enheter anslutna, eftersom när kärnan känner igen alla dina moduler är det bara att kompilera.

    Kärnan kommer att vara väldigt lätt och du kommer att känna en viss friskhet i systemet, samt påskynda start och avstängning av systemet mer.

    Hälsningar.

  26.   Tabris sade

    Livet är inte så enkelt! det finns program som använder cmake eller andra saker, och det tar tid att hålla allt uppdaterat och sammanställt. Och med en sådan CPU, vilken skillnad kommer det att göra för dig?

  27.   yoyo sade

    Problemet med att kompilera är att vissa av programmen som vi installerar med den metoden inte avinstalleras eller ger fel när vi gör det, så vi kan inte avinstallera dem.

    1.    anonym sade

      Du måste spara mappen med de kompilerade källorna. När du vill avinstallera är allt du behöver göra att gå till källmappen och från en terminal som root execute:

      # gör avinstallation

      Naturligtvis installeras paketen för hand som standard i varje seriös distro separat, det vill säga i / usr / local / bin inte i / usr / bin där distributionspakethanteraren sätter dem som standard, så. är sammanflätad.

  28.   freebsddick sade

    Artikeln tar upp flera intressanta saker men saknar en fruktansvärd kvalitet i dess termer och logiska struktur.

    «I ett körbart program för dess drift genom användning av PROCESSOR för konvertering av det språk som används för att generera koden till binären och assemblern. Det kallas också ofta förpackning. "

    Falskt. en kompilator används faktiskt, den ansvarar för att skicka instruktionerna för ett visst programmeringsspråk till dess motsvarande monteringsspråk och sedan översätta detta till maskinspråk.

    Monteringsspråk är ett minne som återspeglar en grupp instruktioner som finns i chipets register.

    "När du laddar ner, dekomprimerar och kompilerar källkoden till ett program själv, kompileras det med de specifika instruktionerna från DIN processor"

    När du kompilerar ett program kommer det helt enkelt att göras med de instruktioner som är gemensamma för arkitekturen, det beror på varje användare att aktivera motsvarande kompilatorflaggor för att optimera ett program för en specifik processor.

    När det gäller vad du kommenterar för att sammanställa kärnan:
    När du kompilerar kärnan letar du efter att aktivera eller inaktivera funktioner som kan vara användbara vid en viss tidpunkt, vilket inte nödvändigtvis kommer att återspeglas i storleks- och hastighetsförhållandet i körningsbelastningen.

    När du hänvisar till följande avsnitt:

    dh-make devscripts fakeroot debhelper debian-policy ccache dh-autoreconf autotools-dev build-dep

    Dessa program är inte nödvändiga för att sammanställa ett program. Som du försökte säga i början, förhindrar antalet programmeringsspråk att du säkert vet vilka verktyg du måste ha installerat för att kunna kompilera program i GNU / Linux ... du kan bara veta det genom att konsultera dokumentation för det program du vill genomföra. De program du nämner används för att DEBANISERA och paketera i detta format ett program som kanske eller inte kan kompileras.

    Det finns andra frågor i artikeln som visar sig vara något tvetydiga i sitt sätt. Det skulle vara svårt att ta itu med dem alla.

    Jag föreslår granskning av artikeln så långt som möjligt av dess skapare och uppmanar till en bättre kontroll av publikationernas kvalitet.

    1.    pepenrike sade

      Man, det är inte det heller.

      Artikeln är inte för Science-tidningen, den är helt enkelt en inledande artikel, och jag tror att i de termer som den är skriven är den tillräckligt djupgående för en nybörjare att förstå nyckelbegreppen.

      Om vi ​​blir akademiska skulle tre fjärdedelar av det som publiceras på internet vara absolut ingenting värt.

      Låt oss inte vara så puristiska ... det är omöjligt att komma överens med 100% med en artikel, men vi kan inte heller kontinuerligt bedöma "teknisk" kvalitet, som om vi utvärderade en doktorsexamen.

      Mitt fulla stöd till författaren till den här artikeln

  29.   icke namngiven sade

    intressant artikel

    Det är alltid bra för frihetsälskare att använda unar istället för rar för att packa upp rars fritt. ( https://packages.debian.org/jessie/unar )

  30.   Jumi sade

    Jag träffade felet med det här problemet ... Jag började söka i google men jag kan inte hitta en tutorial för att kompilera firefox under ubunto 14.04 amd64 bitar ... annars får jag kärnan med följande tutorial: http://www.redeszone.net/2014/11/28/como-instalar-el-ultimo-kernel-de-linux-en-ubuntu-14-04-lts/

  31.   carlos ferra sade

    bra artikel, jag lär mig mycket. men jag skulle bara använda detta för något specifikt program som förbrukar mycket resurser, som videoredigerare till exempel. Hälsningar.

  32.   babel sade

    Mellan den här artikeln och Gentoo-en som de publicerade för några dagar sedan frestar de mig att installera Gentoo på min dator. För många år sedan använde jag Sabayon, vilket underlättade hela installationsprocessen men behöll basen som ska kompileras från källan. Jag kommer helt klart inte ihåg att jag märkte någon skillnad i prestandan på min bärbara dator (vid den tiden hade jag ett varv) med Sabayon eller Ubuntu, så jag vet inte om jag ska kasta mig allt arbete med att radera min Arch som fungerar mycket bra för att installera den. Jag är inte säker på att några millisekunder per program är värt det.

    1.    anonym sade

      Av de 4 datorerna med gentoo som jag har installerat och uppdaterat, läggs den bärbara datorn som hade archlinux till ... Systemd tröttade mig, jag var redan tvungen att använda den med startx eftersom i den senaste uppdateringen sköt båda kärnorna till 85% av användningen, utan att göra ingenting, jag undersökte och det verkar som om något har förändrats i systemd för att göra slim galen och äta mikroprocessorn.
      Tillräckligt, det räckte med båge ... för länge hölls det, mer än två år, nu installerar jag gentoo, jag går till stage3-testuppdateringen, för ikväll kommer en openbox med pommes frites.

  33.   Leo sade

    Bra artikel, det får mig att vilja kompilera Qupzilla, men med ett sempron tar det dagar, ja, jag vet inte så mycket, men det ger ändå ett dåligt resultat.

  34.   Manuel Aponte sade

    En annan nackdel med kompileringen är att när det finns en uppdatering är det nödvändigt att kompilera och installera uppdateringen igen, vilket är ett problem med tanke på att vissa program har korta utvecklingscykler och för dem utfärdas uppdateringar ofta, 2 till 3 månader, med alla detta blir den avslappnade användaren uttråkad och den ständiga användaren tar mycket tid på att hålla sitt system uppdaterat.

  35.   Manuel Aponte sade

    Jag skulle vilja veta vilka applikationer som är mer rekommenderade att kompilera. beroende på dess användbarhet, uppdateringsfrekvens och prestationsförbättring.

  36.   Alex Pol sade

    Detta är absurt, om du behöver kompilera dig använder du fel distribution. Den enda anledningen att kompilera är att lägga till felsökningsalternativ för att sakta ner dig, i utbyte mot bättre fixning av andras buggar.
    Ditt system är inte långsamt eftersom det behöver -O3, det är långsamt eftersom det finns något program som läser för mycket på skivan eller målar för mycket på skärmen.

    Min rekommendation: istället för att mikrooptimera vårt system, låt oss arbeta som en community för att förbättra den programvara som vi alla har.

  37.   Javier Fernandez sade

    Du har inte förklarat hur man kan optimera sammanställningen, till exempel i Gentoo ANVÄNDNING används alternativ för att optimera den genererade koden, du måste också ange processorn etc. Hur görs det i UBUNTU / Debian eller Arch?, Intressant artikel.

  38.   Jose Manuel sade

    Bra!

    I avsaknad av att läsa kommentarerna nedan har jag en nybörjare i Linux:

    Jag använder Fedora 20, jag har redan installerat en hel del saker, till exempel Firefox-webbläsaren, för att kompilera den för min maskin, kan jag bara göra det? Det vill säga under koden och kompilera det, eller måste jag först eliminera programmet som jag redan har laddat ner för att kompilera det nya ...

    Samma sak med Linux-kärnan och sådant….

    Kanske frågar jag något absurt men jag säger redan att jag är ganska nybörjare i de allvarliga Linux-grejerna

    Hälsningar!

    1.    Koprotk sade

      Jag tror att kärnan inte är nödvändig, men du måste skapa en post för varje kärna i GRUB, med firefox vet jag inte om det rekommenderas att ha 2 firefox, personligen föredrar jag att ha bara 1 kärna och 1 bara firefox

  39.   st-avapxia sade

    Det enda jag har sammanställt i mitt liv har varit en version under utveckling av Musique, jag gillar verkligen den appen, den var värt hela tiden det tog för processen. För en slutanvändare som jag, när jag var klar, kände jag mig uppfylld.

    Hälsningar, utmärkt blogg.

  40.   ekoslacker sade

    Hej, jag använder Slackware och att kompilera applikationerna är det vanligaste i världen.
    Systemet installeras från en ISO som redan är förkompilerad och de förkompilerade applikationerna som du kan använda från det officiella arkivet är få, men om du vill kan du ladda ner källkoden för systemet (och originalskripten som hela distro kompileras med ) och sammanställ det själv vilket är hur jag föreställer mig att Gentoo fungerar.
    Men SlackBuilds-projektet tillhandahåller skript (som liknar den officiella distro) för många tredjepartsapplikationer, där du laddar ner källkoden för vad du vill installera och konverterar den till ett tgz- eller txz-paket som senare installeras med det. distros officiella pakethanterare. Därför är fördelen att du undviker att använda konfigurera, skapa, göra installationskommandon och du kan uppdatera, installera om eller ta bort paketet som alla andra och mycket enkelt.
    Nackdelen är att beroenden inte löses automatiskt i Slackware som andra distros, så du måste kompilera nödvändiga beroenden först och applikationen du vill installera sist. De kompilerade programmen som jag använder är från LibreOffice, Texmaker, Spyder, Qt5, QtCreator, VLC, Wine, GRASS, QGis, bland andra. Beroende på applikationen och dess krav kan sammanställning och installation ta allt från 5 minuter till flera timmar. Men om du vill kan du hitta och använda ett färdigt kompilerat paket för att spara tid.
    Jag har inte haft tid att kontrollera om det finns stor skillnad mellan kompilerade och förkompilerade paket, men mitt system är mycket stabilt. Men jag tror att åtminstone i min bärbara dator är det inte så stor skillnad eftersom den inte är så kraftfull, den har en i3-processor och 4 GB RAM.
    Hälsningar och lycka till att sammanställa.

  41.   Koprotk sade

    Jag använder för närvarande Funtoo, för att vara ärlig ser jag ingen prestandaskillnad mellan att kompilera ett program eller installera det förkompilerade, jag gör det enbart för ett pedagogiskt ändamål, men om det finns skillnader mellan att kompilera kärnan och inte göra det, ja. När jag använde debian och ville kompilera något använde jag följande sekvens:

    . / Configure
    Make -j3 (antal kärnor + 1)
    Främmande

    Jag använde alíen eftersom det skapar ett binärprogram för det kompilerade programmet och så att du kan installera det på ditt system som valfritt binärt, och så, om du vill avinstallera, kan du helt enkelt använda synaptic eller en annan pakethanterare, det är fördelen med att skapa paketet och installera paketet som sådant istället för att göra "gör installation"

    1.    yukiteru sade

      Jag ser en förbättring, åtminstone med stora och tunga paket, till exempel Libreoffice i Funtoo tar mycket mindre tid att ladda än i Debian, detsamma har hänt mig med VLC eller med mpv och MKV FullHD och multiljudfiler, belastningen är mycket snabbare.

      En annan som också har genomgått förändringen är Firefox, i Debian blir 10 eller 15 flikar med min dator tortyr, men med Funtoo har jag lyckats ha upp till 30 öppna och det fortsätter som om ingenting och ramkonsumtionen är mycket lägre och mindre Jag brukar frysa för JS-filer, jag tror att det beror mer på sammanhanget på hur vissa uppgifter och program körs.

  42.   Marco Sarmiento sade

    Problemet är att när vi laddar ner den förkompilerade förvandlar vi alla Linux-distro till en rå kopia av Windows

  43.   Fermín sade

    Mer än i en spektakulär prestationsökning, ser jag fördelen med möjligheten att kompilera paketen med de komponenter som man vill ha: om du till exempel inte har en skrivare kan du ange att paketen med stöd för CUPS inte är kompilerade -paketen som de använder CUPS, självklart, om du kompilerar Hunspell med eller utan CUPS spelar det ingen roll- bara-åtminstone i Gentoo- indikerar i make.conf-filen, där alla alternativ för att bygga paket är centraliserade "-cups "; om du använder KDE5 eller Plasma 5, som de kallar det nu, kan du ange taggarna "-kde", "-qt4", som var giltiga taggar för KDE 4 men onödiga i KDE 5 och applikationer som porteras till det nya skrivbordet, "-gnome", "-Gtk" och så vidare med alla komponenter du vet att du inte behöver. Om ett visst program av någon anledning behöver, låt oss säga GTK, kan du i en fil som heter package.use ange att det använder GTK, till exempel för Pidgin med samma etikett men utan minustecknet, det vill säga " gtk »:« Net-im / pidgin gtk ».
    På detta sätt uppnås ett system som är flera hundra megabyte lättare och mindre och effektivare binärer, eftersom det inte har onödig kod. Jag har gått från Ubuntu till Gentoo genom Opensuse, Kubuntu, Debian, Arch, Chakra eller KaOS, och Gentoo är det snabbaste systemet jag har haft, och jag har fortfarande samma Core 2 Duo som jag hade för 7 år sedan. Naturligtvis lämnar jag kompileringarna för natten, för att exempelvis ta QT5 tar flera timmar. Om du ställer in parametern "trevlighet" för Portage i make.conf kan du installera paket eller uppdatera medan du fortsätter arbeta med maskinen och du märker knappt mycket avmattning, även om sammanställningstiden uppenbarligen ökar; men kom igen, med att sätta den på att installera eller uppdatera när jag går till middag, och om det behövs låta den fungera över natten, fungerar min gamla dator bättre än min flickväns I3 med Kubuntu.

    En annan allt viktigare aspekt är att när vi kompilerar från källfiler är säkerheten som paketet vi installerar är den ursprungliga, att den inte har manipulerats av tredje part, nästan total. Jag tror att Debian implementerar ett byggverifieringssystem som garanterar lite mer än den förkompilering vi installerade faktiskt kommer från den ursprungliga källan, men det kommer aldrig att finnas så mycket säkerhet när det paketet har kompilerats på vår maskin med vår installation.
    Enligt min mening, med en modern processor, inte en spärr som min, hehe, och om vi vill påskynda processen med 8 GB RAM för att kunna montera / var / tmp - den tillfälliga mappen som Portage använder för sammanställning i RAM, som alltid kommer att vara snabbare än en hårddisk eller en SSD, idag ser jag inte mycket mening att använda förkompilerade paket. Om det tar ungefär 40 minuter att kompilera min Firefox-dator, hur lång tid kan det ta för en I5 eller en I7 som för närvarande finns på marknaden, 5 minuter, ännu mindre? Jag pratar om källan firefox, inte firefox-bin, som är ett förkompilerat binärt paket som kan installeras på Gentoo om du har en mycket långsam maskin - det finns flera stora paket som redan erbjuds förkompilerade av den anledningen, det är inte obligatoriskt att sammanställa allt -. Jag kan inte prata för att min flickvän inte låter mig fikla med sin dator, hehe, och min går så bra att jag inte känner behov av att förnya den, men om jag har rätt tycker jag att det är värt att slösa några minuter kompilera för att få ett system att mäta. Mer anpassad och anpassad till vår maskin tror jag inte att någonting kan uppnås utan att gå in på dessa Linux-metoder från grunden, Linux från grunden, vilket jag tror redan är reserverat för datavetare eller mycket avancerade Linux-finsmakare.

    Hälsningar.

  44.   Anka sade

    Mycket bra!
    en enda sak existerar inte "Amd Atom x2"
    ni existira är ett varumärke som tillhör Intel
    gäller