I den här lilla guiden ska jag förklara (och lära dig) varför det är bättre att kompilera 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.
Låt oss börja med teorin:
Vad är "kompilera"?
Att kompilera är att omvandla källkoden (koden skriven i ett visst programmeringsspråk, säg C, C++, etc) till ett körbart program för dess funktion genom att använda processorn för konvertering av språket som används för att generera koden till binär och assembler ... Det kallas också ofta för 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.), varje ras (Pentium, Core, Atom, etc.) och dess typ (Intel, AMD, ARM, etc.) av processor har instruktioner (skriven programvara i assembler som bearbetar koden) för sin modell (Core i7, Core i5, Atom x2, Phantom x8, Arm, etc) och har även allmänna instruktioner som alla av dess slag har.
När du laddar ner från arkiven via Software Center/apt-get/Yumex/Yum/Pacman/etc, sägs ett program som installeras automatiskt vara detta förkompilerad för dess drift på alla möjliga processorer (Intel och Amd). Eftersom det är ett förkompilerat program går de instruktioner som är specifika 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, måste lägga alla specifika instruktioner för varje processor på marknaden skulle mängden kod vara så stor att det här programmet inte längre skulle vara effektivt), vilket inte lämnar något mer än de allmänna av dess skaparmärke (Intel, Amd, Arm).
När du själv laddar ner, dekomprimerar och kompilerar källkoden för ett program, kompileras den med specifika instruktioner 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 rent för din processor), på så sätt släpper lös och frigör all kraft som din processor kan ge tack vare dess specifika instruktioner.
I mer teknisk detalj är dessa specifika instruktioner nära knutna till vad som kallas ditt moderkortschipset, vilket är den stora huvudvärken för oss på 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, i3etc från din gamla dator. Förstår du nu varför det pratas mycket i Linux-världen om att kompilera den berömda kärnan (hjärtat i varje operativsystem)? Föreställ dig om du kompilerar ett helt system speciellt för din PC (grafisk miljö (Gnome, Kde, etc), Kernel, vanliga program (Firefox, Vlc, Chrome, Wine, etc.) alla nivåer av hastighet och optimering du skulle ha.
Denna kompileringsprincip för att få en kod optimerad speciellt för din maskin är den som används av distros som Gentoo och derivator (som jag inte ska prata om nu, jag använder Fedora minimalt med kompilering av Gnome 3, kärnan och andra program) där systemet, dess uppdateringar och dess program alltid alltid kompileras.
Nackdelar med sammanställningen:
Jag har redan förklarat alla fördelar, men som allt i universum har det en baksida.
När det gäller byggnaden är de;
- Tid som behövs för detta (Firefox med en i7 4790K (utan överklockning eftersom jag är riktigt dålig på spänningar) tar 3 minuter, Gnome Shell (bara baren) med Gnome-Control-Center tar mig cirka 2 minuter, båda kompileras på samma tid på Fedora, men på en maskin med en mindre kraftfull processor kan denna tid öka orimligt).
- Processorn använder 100% av sin kraft med alla sina kärnor maximalt, så förbrukningen och värmen skjuter i höjden (ta hänsyn till detta om den är överklockad 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 ett program använder så att det inte misslyckas i kompileringen. I allmänhet har alla distros paket eller uppsättningar av dem för att undvika detta (de kommer fulla av olika bibliotek och andra saker som gör att kärnan kan kommunicera korrekt med processorn under processen).
Hur kan jag kompilera?
Här pratar jag om att kompilera ett program för normal användning, inte en kärna.
aptitude install 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 du får ett felmeddelande om att det här paketet inte finns, ignorera det bara. Jag måste förtydliga att jag inte har använt dessa system på länge, så om ett paket inte längre finns i arkiven, oroa dig inte.
För Fedora:
sudo yum -y installera kernel-headerskernel-develsudo yum groupinstall "Utvecklingsverktyg"sudo yum groupinstall "Utvecklingsbibliotek"
Här måste jag be om ursäkt till de som använder Arch (jag känner inte till distron så bra) och OpenSuse, eftersom jag inte kan dessa distros eller respektive paket för att utföra en korrekt kompilering (och jag har inte verifierat vad som finns på nätet, så jag vet inte om de fungerar för dessa två).
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, packa upp det med terminalen (oroa dig inte, jag lämnar kommandona till dig) och när du går till mappen (alltid med terminalen) gör du följande:
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
Kommandon för att packa upp med terminalen (filen packas upp i en mapp där filen finns):
.tar-filer (tar) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Paket | 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) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Packa och komprimera | tar csvf file.tar.gz /file/ Packa upp och packa upp | tar xzvf file.tar.gz Visa innehåll (utan att extrahera)| tar tzvf file.tar.gz
- - - - - - - - - - - - - - - - - - - - - - - - - - - .gz (gzip) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Komprimera | gzip -q-fil (Filen är komprimerad och döpt om till "file.gz") Packa upp | gzip -d file.gz (Filen dekomprimerar den och lämnar den som "fil" Obs: gzip komprimerar bara filer, inte kataloger
- - - - - - - - - - - - - - - - - - - - - - - - - - - - .bz2 (bzip2) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Komprimera | bzip2-fil | bunzip2-fil (Filen komprimerar den och döper om den till "file.bz2") Packa upp | bzip2 -d file.bz2 | bunzip2 file.bz2 (Filen dekomprimerar 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 Packa upp | bzip2 -dc file.tar.bz2 | tar -xv | tar jvxf file.tar.bz2 (senaste versioner av tar) Visa innehåll | bzip2 -dc file.tar.bz2 | tar-tv
- - - - - - - - - - - - - - - - - - - - - - - - - - - .zip (zip) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Komprimera | zip file.zip /may/files Packa upp | packa upp file.zip Visa innehåll | packa upp -v file.zip
- - - - - - - - - - - - - - - - - - - - - - - - - - - .rar (rar) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Komprimera | rar -a file.rar /may/files Packa upp | rar -x archive.rar Visa innehåll | rar -v file.rar | rar -l fil.rar
Och det är allt. Hälsningar från Buenos Aires, Argentina. Glad helg och nytt år! :).
Problemet med att kompilera är att det inte alltid fungerar första gången och att det är mer tråkigt.
Problemet med att kompilera är att om du inte har en gammal och begränsad dator kommer förbättringarna inte att märkas särskilt mycket... 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.
Jag tror att det är kärnan i saken. Är prestandaförbättringen du kommer att märka när du kompilerar paketen så viktig att det skulle ta bortkastad tid och krångel med att kompilera i bakgrunden?
Samma sak om du har en i7 som kompilerar är det bekvämt, eftersom det är snabbare och jag räknar ut att det fungerar något bättre. Nu med en dator med intel atom är det inte bekvämt, om du inte verkligen behöver den där extra kraften som den ger för att kompilera, men det kan ta timmar att kompilera ett program med en mindre kraftfull processor.
Jag håller helt med, det har hänt mig från att kompilera och efter ett tag få reda på att man saknar ett bibliotek, spåra upp det och behöva möta processen igen... Det är sällan allt fungerar vid första försöket... xD
Mycket intressant!
Om du kompilerar ett program, hur fungerar uppdateringarna efteråt? Är de automatiska eller måste vi vara medvetna om om en ny version har kommit ut?
Du måste uppdatera den manuellt, det vill säga kompilera den senaste versionen, det är en annan "nackdel" för vilken det också är lite tråkigt.
Nåväl, uppdateringar finns inte, faktiskt, linux-distributioner och deras olika sätt att paketera programvaran och motsvarande pakethanterare eliminerar besväret med att kompilera om för varje ny uppdatering (och lösa beroenden).
Hälsningar.
Om du kompilerar det genom att ladda ner källkoden från någon sida, måste du göra det manuellt och lära dig hur du installerar det eftersom inte alla är installerade på samma sätt.
Nu, om du har Gentoo eller någon distro med portar, så gör du det nästan automatiskt från arkiven.
I Gentoo tar deras pakethanterare, Portage, hand om uppdateringar och beroenden; Jag vet inte om andra distros. Naturligtvis innebär varje uppdatering omkompilering, så klart.
Det fanns en tid då jag sammanställde allt jag kunde. Sedan blev jag trött, speciellt på grund av den tid jag fick ägna åt att få maskinen att fungera (45 min för kärnan, 10 min för krom...) och tiden jag ägnade åt att fixa problem som uppstod i farten. Dessutom hittade jag personligen ingen prestationsökning, jag hade en känsla av att allt var sig likt. Av dessa skäl använder jag nu allt förkompilerat, allt är omedelbart och utan konflikter. Även om jag lärde mig mycket under den tiden, ville jag fortfarande använda gentoo 🙂
Till och med, och det är något jag sällan har sett, kan det kompileras från system som apt. Lägg till en build-flagga till apt-source och du är klar. Självklart, innan dess, installera de nödvändiga paketen för att utföra kompileringarna, annars fungerar det inte... även om det är ett mer direkt sätt att kompilera och kräver färre steg, eftersom det bara tar upp installationen första gången av paket och följande, beroenden uppfyllda och paketet som sådant.
Hälsningar.
Den har apt-build-funktionen, även om jag tror att den inte bygger beroenden, den installerar förbyggda binärer istället.
Från 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 en idé i huvudet som snurrar runt, 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 "aktuella behov" är oförlåtligt, eftersom det inte gäller.
Kanske behöver vi något i mitten, där varken bibliotek eller detaljer om versionsändringar kommer att få oss att slösa bort så mycket tid. Vi får se vad som händer då, eller om vi verkligen ägnar oss åt att kompilera ovanpå aptitude, uprmi och zypper som vi redan har installerat.
3 minuter firefox!... skulle du ha menat 30?
Detta tar tid 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, därför kompileras för ett program att köras på många typer av mikroprocessorer, ja eller om de måste begränsas till det minsta mängden vanliga mnemonics som stöds på alla dessa mikroprocessorer ... slösar bort verklig kapacitet hos de mest aktuella och kraftfulla mikroprocessorerna.
Så här gör företag och binära distributioner av gnu/linux.
För mig, med en Intel i7 4790K med 18gb RAM, har det jag sa tidigare tagit mig
Jag förstår att mikron du har är överlägsen, men skillnaden är urusel, sanningen måste vara ett lakan i den hastigheten. Kanske är det något relaterat till beroenden eller ANVÄNDNINGAR som är samma som konfigureringsalternativen när man kompilerar för hand.
Liten detalj som man glömde säga 18GB Ram förutom i7, alla har inte den maskinen, men man skulle kunna göra en benchmarking så att skillnaden syns lite, för teorin är trevlig men får se om det kompenserar.
en annan stor detalj, processorn är intel, därför har den den bästa flyttalsmodelloberoende, en mycket relevant funktion för att utföra denna typ av process
Det är sant att det är tråkigt att kompilera. Men du lär dig mycket genom att avstå från Makefiles, bibliotek osv. 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!
Problemet jag generellt sett har när jag försöker kompilera helt nya versionsprogram beror alltid på beroenden, ibland är det dags att kompilera alla (för att komma till de senaste versionerna) och sedan tänka på att kunna kompilera det man vill.
PATH-problem och FLAGS är de saker som fortfarande hindrar mig från att vilja kompilera allt (även om jag vanligtvis gör det hur jag kan). Ett av de verktyg som jag brukar använda för att kunna 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 kompilera källkoden som du behöver använda i systemet... (98% av vad jag har behövt för att kompilera har jag uppnått genom att guida mig själv härifrån och lite av lite lärande).
Som en punkt för, tror jag att det skulle vara intressant att kompilera ett system från grunden, speciellt för utvecklingsmiljöer eller servrar, bland annat som, låt oss säga, "vanligen inte är lika föränderliga" som en persondator som vi ständigt installerar i. och att ändra allt (det är min synvinkel) utöver det faktum att den minsta prestanda som uppnås i denna typ av applikation är mycket viktig.
Det här är punkter som det pratas väldigt lite om nuförtiden och bara "forskare" hanterar dem, men det är intressant att ge den här typen av saker de tutorials 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 finns kvar i tiden på grund av samarbetspartnernas dåliga prestanda, även om det hittills "har fungerat så här" inte är särskilt hälsosamt att bara ha slutanvändare.
Tillåt mig ett litet tillägg. För att få fördelarna som du visar här måste du konfigurera den välkända make.conf. Där indikeras processorfamiljen och kompileringsflaggorna. På samma sätt kan du där specificera antalet kärnor som ska användas under kompileringen. När du använder alla kärnor på din mikro, reduceras kompileringstiden drastiskt.
hälsningar
Mycket bra artikel. Jag skulle också ha velat ha ett exempel eller direkt, ett inlägg om hur man kompilerar i archlinux eller hur man använder AUR. Gott nytt år från Mendoza.
Länge sedan... Jag kompilerade alltid kärnan, men det är väldigt tråkigt att behöva vänta 40min :/ ja... det var länge sedan jag kompilerade något förutom videodrivrutinerna (bara för vissa speciella konfigurationer).
Artikeln är väldigt intressant, men nej herre, förpackning och sammanställning är inte samma sak ;)..
Mycket bra inlägg. Jag håller med om att kompilera vissa program, men ibland är det lite tråkigt eftersom maskinen tar tid att göra processen. Men förutom det lär man sig mycket, speciellt när man behöver bibliotek eller paket.
Jag tror att för Archlinux behöver du följande paket för att kompilera: base-devel
pacman -S base-devel
Informationen är mycket bra, men sanningen är att det inte är nödvändigt att kompilera, 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 menar, du saknar alltid ett bibliotek, du har ett eller annat problem, säg till mig att kompilera minecraft-servern så att allt blir så bra som möjligt och jag tar dig tid…. Bortsett från det varje gång en uppdatering eller patch eller vad som helst kommer ut, börja kompilera igen xd
Exakt, kompilering är till för väldigt 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, speciellt rullande release-distros, är irriterande. Jag skulle bara rekommendera lts-kärnorna.
Nuförtiden stöder nästan alla processorer som människor använder samma instruktioner, därför är kompilering endast fördelaktigt när det hänvisar till kärnan och i ett system som en server, det, och uppenbarligen när det inte finns några förkompilerade paket, allt annat. av tid.
Bra bidrag, jag ska försöka se hur det går, än så länge installerar jag oftast (nästan alltid) från arkiven...
Liten anmärkning: rar-kommandoalternativen går utan bindestreck och bunzip2 dekomprimerar bara.
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, tiden att kompilera och ladda ner hela systemet skulle ta mig cirka 18 timmar, och att om jag inte har några problem, är det sant att det är bättre att kompilera men för det mesta tar tiden för mycket och jag tycker att det inte är värt det. Du har en hastighetsbonus men det är inte mycket och jag tycker att det inte motiverar all tid som investeras. Fast om jag en dag får ha en dator med en lika bra processor som din så ska jag försöka installera gentoo 😛
Människor:
Inga flamma avsikter eller något, slackers ser det som naturligt att kompilera, bygga binären, installera den med den relevanta pakethanteraren (löser uppenbarligen beroenden, slapt-get, swaret, slackyd och/eller flera andra), med allt optimerat för vårt team och som om ingenting, vilket inte är något speciellt eller kvantfysik.
Att titta på en DVD utan att snubbla runt på en 3MHz P750 med 192MB RAM är varken omöjligt eller svårt att få till på Slackware. Jag intygar, och det är snabbare än att kompilera en Gentoo. Men det är inte samma sak, jag använder också Gentoo.
Skillnaden mellan en hacker och en konsument är att konsumenten säger "jag önskar att det fungerade så" och hackaren "Jag har en skruvmejsel och ett par minuter" - Rael Dornfest
Finns det verkligen en märkbar prestandaförbättring?
Med en sista generationens i7 och 18 Gb ram, hur märker du skillnaden från de kompilerade paketen till binärerna?
Jag har alltid hatat om lämpligheten av självkompilering av paket, men jag tror att det i nuvarande skrivbordsmiljöer är för komplicerat att stödja, särskilt på grund av komplexiteten i beroenden, de kontinuerliga uppdateringarna och det enorma beroendet av icke-gratis källor., som i fallet med proprietära drivrutiner, som utan tvekan påverkar prestandan mycket mer än någon aspekt som kan kompileras...
hälsningar
Med tanke på att Gnome 3 bara kompilerar det (jag ska säga namnen ungefär eftersom jag inte kommer ihåg namnen på paketen): skalet (fältet), gnome-control-center (komplett, med dess beroenden, etc), appleten för tid och cirka 2 eller 3 beroenden för att få skalet att fungera. Uppenbarligen krävde skalet fler beroenden för att alla dess funktioner skulle fungera men det ledde till att jag kompilerade bland annat GDM, jag fixade detta genom att modifiera det med GConf när skalet kompilerats.
Nu när jag loggar in (via terminal) tar miljön mycket kortare tid att ladda än när jag hade den installerad förkompilerad. Jag kastar lite 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 för att skärmens bakgrund skulle visas, jag förstod aldrig varför det tog så lång tid, jag tror att det är pga. drivrutinen med GT 630) och kompileras så fort jag skrev in lösenordet, X org startar och miljön laddas (med preload och prelink gjorde jag dem mycket snabbare, jag tror att det beror på att de gick till cachen; https://www.google.com.ar/search?q=preload+y+prelink+fedora&ie=utf-8&oe=utf-8&gws_rd=cr&ei=iXaqVPykO4qYNpbTgdAP )
Det faktum att i7 har ss4- och ss3-instruktioner, som ignoreras av generiska versioner av olika distros (debian kompilerar för 486, ubuntu för 686) kan ge dig en uppfattning om hur mycket hårdvara som går till spillo för att försöka ta emot en 20-åring processor - Tack ändå debian för att du stödjer min gamla pentium mmx-. Om du behöver "proprietära drivrutiner" som du nämner, ger kärnan möjligheten att ladda den specifika firmware vid kompilering. Inga fler konstiga problem med xorg.
Tack för infon, det är alltid bra att lära sig (eller lära sig om) (:
Debian gärna till Gentoo 🙂
http://crysol.org/es/node/699
En annan nackdel är att terminalbygget är för användare som kan eller redan har viss kunskap om Linux. Finns det ett grafiskt verktyg som inte hanterar kompilering, installation och uppdatering av program utan på ett grafiskt sätt?
Beräkna linux gör det, det är en gentoo grafisk verktygslåda redo att kompileras. I Phoronix brukar de rekommendera det.
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 distron i fråga, tror jag att det är viktigt att veta hur man kompilerar, speciellt när du använder dem sällsynta distros.
Allt han säger 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 att kompilera dig själv är omärklig för en användare.
Och nackdelarna med att kompilera är många och de är tydligt märkbara för användaren. Därför personligen går jag att kompilera.
Där jag mest har märkt prestandan när jag kompilerade kärnan var på en bärbar dator med en AMD 64-processor. Bytet mellan fabrikskärnan och den kompilerade var brutal.
Just nu har jag en fabrikskärna i mitt system, för som de säger mycket här, det fanns en tid när jag kompilerade nästan allt och jag blev trött.
Just nu kompilerar jag bara några program av avgörande betydelse, 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 versionen av mame. Dessa program är i allmänhet märkbara när du har dem optimerade för ditt system.
Jag behöver bara testa den där gentoo-distron och se hur det går.
Jag glömde att lägga till, för personer som lägger mycket tid på att kompilera kärnan, mer än 30 minuter, finns det flera knep för att göra det på kortare tid.
Ett av dessa knep är att, bara kompilera modulerna för din utrustning, maximalt, kanske högst 70 moduler är vad som kommer att 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 över 3000 moduler, en siffra som för närvarande fungerar om kärnmodulerna kompileras som de kommer från fabriken eller som man 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 använder det här skriptet "streamline_config.pl" som finns inuti kärnans källkodskatalog, i sökvägen "/scripts/kconfig". / »
Men se till att du har alla dina usb-enheter inkopplade, för när kärnan väl känner igen alla dina moduler är det bara att kompilera.
Kärnan kommer att vara mycket lätt och en viss friskhet kommer att kännas i systemet, samt snabbare start och avstängning av systemet.
Hälsningar.
Livet är inte så lätt! det finns program som använder cmake eller andra saker, även att hålla allt uppdaterat och kompilerat tar tid. Och att ha en sådan CPU, vilken skillnad kommer det att göra för dig?
Problemet med att kompilera är att vissa av de program som vi installerar med den metoden sedan inte avinstallerar eller ger fel när de gör det, så vi kan inte avinstallera dem.
Du måste spara mappen med de kompilerade källorna, när du känner för att avinstallera, allt du behöver göra är att gå till mappen källkod och från en terminal som root exekvera:
# gör avinstallation
Naturligtvis installeras paketen som kompileras för hand som standard i alla seriösa distros separat, det vill säga i /usr/local/bin, inte i /usr/bin där distrons pakethanterare placerar dem som standard, så här kommer inget in vägen.
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 språket som används för att generera koden till binär och assembler. Det kallas också ofta för buntning.»
Falsk . en kompilator faktiskt används, den ansvarar för att skicka instruktionerna för ett visst programmeringsspråk till dess motsvarande på assemblerspråk och sedan översätta detta till maskinspråk.
Assembly language är ett minnesmärke som återspeglar en uppsättning instruktioner som finns i chipets register.
"När du laddar ner, dekomprimerar och kompilerar källkoden för ett program själv, kompileras den med de specifika instruktionerna från DIN processor"
Vid kompilering av ett program kommer det helt enkelt att ske med de instruktioner som är gemensamma för arkitekturen.Det är upp till varje användare att aktivera motsvarande kompilatorflaggor för att optimera ett program för en specifik processor.
Angående vad du säger om att kompilera kärnan:
När du kompilerar kärnan är du ute efter att aktivera eller avaktivera funktioner som kan eller inte kan vara användbara vid ett visst tillfälle, vilket inte nödvändigtvis kommer att återspeglas i storleken och hastighetsförhållandet i exekveringsbelastningen.
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 kompilera ett program. Som du försökte säga i början, antalet programmeringsspråk gör det omöjligt att säkert veta vilka verktyg du måste ha installerat för att kunna kompilera program i gnu/linux... du kan veta det bara genom att konsultera dokumentationen för programmet du vill göra. Programmen du nämner används för att gå vidare till DEBIANIZE och paketera i det formatet ett program som kanske är kompilerat eller inte.
Det finns andra frågor i artikeln som visar sig vara något tvetydiga i sättet de tas upp. Det skulle vara svårt att ta itu med dem alla.
Jag föreslår en revidering av artikeln så långt som möjligt av dess skapare och en bättre kontroll av kvaliteten på publikationerna efterlyses.
Man, det är det inte heller.
Artikeln är inte för tidskriften Science, det är bara en introduktionsartikel, och jag tror att i de termer som den är skriven är den tillräckligt djup för att en förstagångsanvändare ska förstå nyckelbegreppen.
Om vi blir akademiska skulle tre fjärdedelar av det som publiceras på internet vara värt absolut ingenting.
Låt oss inte vara så purister... det är omöjligt att hålla med till 100% om en artikel, men vi kan inte heller kontinuerligt bedöma den "tekniska" kvaliteten, som om vi skulle utvärdera en doktorsexamen.
Mitt fulla stöd till författaren till denna artikel.
intressant artikel
Det är alltid bra för frihetsälskare att använda unar istället för rar för att dekomprimera rar gratis. ( https://packages.debian.org/jessie/unar )
Jag blev biten av det här problemet... Jag började söka på google men jag kan inte hitta en handledning för att kompilera firefox under ubunto 14.04 amd64-bitar... för resten, ikväll börjar jag med kärnan med sig tutuo: http://www.redeszone.net/2014/11/28/como-instalar-el-ultimo-kernel-de-linux-en-ubuntu-14-04-lts/
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.
Mellan den här artikeln och Gentoo-artikeln du postade för några dagar sedan är jag frestad att installera Gentoo på min PC. 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ällkod. Jag minns ärligt talat inte att jag märkte någon skillnad i prestanda på min bärbara dator (på den tiden hade jag ett varv) med Sabayon eller med Ubuntu, så jag vet inte om jag ska lägga in allt arbete med att ta bort min Arch som fungerar mycket bra att installera det. Jag är inte säker på att några millisekunder per program är värt det.
Av de 4 st med gentoo som jag har installerat och uppdaterat, läggs notebooken som hade archlinux till... Jag tröttnade på systemd, jag var redan tvungen att använda den med startx för i den senaste uppdateringen sköt användningen av båda kärnorna till 85%, utan att göra någonting, jag undersökte och det verkar som att något har ändrats i systemd så att slim blir galen och äter upp mikroprocessorn.
Det räcker, det räckte med arch...det varade för länge, mer än två år, nu installerar jag gentoo, jag går för uppdateringen till stage3-testning, för ikväll kommer en openbox med chips att fungera.
Bra artikel, det får mig att vilja kompilera Qupzilla, men med ett sempron kommer det att ta dagar, ja, jag vet inte så mycket, men det suger fortfarande.
En annan nackdel med att kompilera är att när det finns en uppdatering är det nödvändigt att kompilera och installera uppdateringen, vilket är ett problem med tanke på att vissa program har korta utvecklingscykler och uppdateringar utfärdas ofta, 2 till 3 månader, med allt detta den tillfälliga användaren blir uttråkad och den konstanta användaren lägger ner mycket tid på att hålla sitt system uppdaterat.
Jag skulle vilja veta vilka applikationer det rekommenderas att kompilera. efter dess användbarhet, uppdateringsfrekvens och prestandaförbättring.
Detta är absurt, om du behöver kompilera dig själv använder du fel distribution. Det enda skälet att kompilera är att lägga till felsökningsalternativ och sakta ner dig själv, i utbyte mot att du bättre kan fixa andras buggar.
Ditt system är inte långsamt eftersom det behöver -O3, det är långsamt eftersom något program läser för mycket från disken 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 gemenskap för att förbättra mjukvaran vi alla har.
Du har inte förklarat hur man optimerar kompileringen, till exempel i Gentoo används USE-flaggorna för att optimera den genererade koden, man måste även ange processorn osv. Hur görs detta i UBUNTU / Debian eller i Arch?, Intressant artikel.
Bra!
I avsaknad av att läsa kommentarerna nedan har jag en fråga och nybörjare till linux:
Jag använder Fedora 20, jag har redan en hel del saker installerade, till exempel webbläsaren Firefox, för att kompilera den för min maskin, kan jag bara göra det, det vill säga jag laddar ner koden och kompilerar den, eller har jag först för att ta bort programmet som redan finns? Jag har laddat ner för att kompilera det nya...
Samma sak med Linux-kärnan och så...
Jag kanske frågar något absurt men jag har redan sagt att jag är ganska ny på det seriösa med Linux hahaha
Hälsningar!
Kärnan tror jag 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 är att rekommendera att ha 2 firefox, personligen föredrar jag att bara ha 1 kärna och 1 bara firefox
Det enda jag har sammanställt i mitt liv har varit en utvecklingsversion av Musique, jag gillar verkligen den appen, den var värd all tid som processen tog. För en slutanvändare som jag kände jag mig uppfylld när jag var klar.
Hälsningar, jättebra blogg.
Hej, jag använder Slackware och att kompilera applikationer är det vanligaste i världen.
Du installerar systemet från en redan förkompilerad ISO, och de förkompilerade applikationerna som du kan använda från det officiella arkivet är få, även om du vill kan du ladda ner källkoden för systemet (och de ursprungliga skripten som hela distron är kompilerad med och kompilera det själv vilket är så jag föreställer mig att Gentoo fungerar.
SlackBuilds-projektet tillhandahåller dock skript (liknande de officiella från distro) för många tredjepartsapplikationer, där du laddar ner källkoden för det du vill installera och konverterar det till ett tgz- eller txz-paket som senare installeras med den officiella pakethanteraren för distron. Därför är fördelen att du slipper använda kommandona configure, make, make install och du kan uppdatera, installera om eller ta bort paketet som vilket annat och mycket enkelt.
Nackdelen är att i Slackware löses inte beroenden automagiskt som i andra distros, så du måste kompilera de nödvändiga beroenden först och applikationen du vill installera sist. De sammanställda programmen som jag använder är från bland annat LibreOffice, Texmaker, Spyder, Qt5, QtCreator, VLC, Wine, GRASS, QGis. Beroende på applikationen och dess krav kan kompileringen och installationen ta mellan 5 minuter och flera timmar. Men om du vill kan du hitta och använda ett förkompilerat paket för att spara tid.
Jag har inte hunnit kolla om det är så stor skillnad mellan de kompilerade och förkompilerade paketen, men mitt system är väldigt stabilt. Men jag tror att det åtminstone i min bärbara dator inte är så stor skillnad eftersom den inte är så kraftfull, den har en i3-processor och 4 GB RAM.
Hälsningar och lycka till med sammanställningen.
Jag använder för närvarande Funtoo, om jag ska vara ärlig ser jag ingen skillnad i prestanda mellan att kompilera ett program eller att installera det förkompilerade, jag gör det rent av pedagogiska syften, men om det finns skillnader mellan att kompilera kärnan och att inte kompilera den , ja. När jag använde debian och ville kompilera något, använde jag följande skript:
. / Configure
Gör -j3 (antal kärnor+1)
Främmande
Jag använde alien eftersom det skapar en binär av det kompilerade programmet och så att du kan installera det på ditt system som vilken binär som helst, 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 "make install"
Jag ser en förbättring, åtminstone med stora och tunga paket, till exempel tar Libreoffic i Funtoo mycket mindre tid att ladda än i Debian, samma sak har hänt mig med VLC eller med mpv och MKV FullHD och multiaudiofiler, belastningen är mycket snabbare.
En annan som också har genomgått förändringen är Firefox, i Debian blir det tortyr att ha 10 eller 15 flikar med min PC, men med Funtoo har jag lyckats ha upp till 30 öppna och det fortsätter som om ingenting och förbrukningen av ram är mycket lägre och mindre tenderar att frysa på grund av JS-filer, jag tror att det beror mer på sammanhanget på hur vissa uppgifter och program körs.
Problemet är att när vi laddar ner det förkompilerat konverterar vi vilken linux distro som helst till en grov kopia av Windows
Mer än en spektakulär prestandahöjning 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 indikera att paketen med stöd för CUPS inte är kompilerade -paketen som de använder CUPS, uppenbarligen, om du kompilerar Hunspell med eller utan CUPS spelar det ingen roll- bara -åtminstone i Gentoo- anger i make.conf-filen, där alla alternativ för att bygga "-cups" paket är centraliserade; 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 portade till det nya skrivbordet, "-gnome", "-gtk" och så vidare med alla komponenter du vet att du inte behöver. Om ett specifikt program av någon anledning behöver, låt oss säga GTK, så 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å så 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 någonsin haft, och jag har fortfarande samma Core 2 Duo som jag hade för 7 år sedan. Självklart lämnar jag sammanställningarna för natten, eftersom att sammanställa QT5 till exempel tar flera timmar. Om du ställer in parametern "niceness" för Portage i make.conf kan du installera paket eller uppdatera medan du fortfarande kör maskinen och knappt märka någon avmattning, även om kompileringstiden uppenbarligen ökar; men hallå, med att installera eller uppdatera den när jag går på middag, och om det behövs låta den fungera över natten, så fungerar min gamla dator bättre än min flickväns I3 med Kubuntu.
En annan allt viktigare aspekt är att när man kompilerar från källfiler är det nästan total säkerhet att paketet vi installerar är det ursprungliga, att det inte har manipulerats av tredje part. Jag tror att Debian implementerar ett byggverifieringssystem som kommer att ge lite mer garanti för att det förkompilerade vi installerade faktiskt kom från den ursprungliga källan, men det kommer aldrig att finnas så mycket säkerhet när det paketet har byggts på vår maskin med vår konfiguration.
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 temporära mappen som Portage använder för kompilering- på RAM, som alltid kommer att vara snabbare än en hårddisk eller SSD, för närvarande ser jag inte mycket mening med att använda förkompilerade paket. Om Firefox tar cirka 40 minuter att kompilera på min dator, hur lång tid kan det ta på en I5 eller I7 som för närvarande finns på marknaden, 5 minuter, ännu mindre? Jag pratar om firefox source, inte firefox-bin, som är ett förkompilerat binärt paket som du kan installera på Gentoo om du har en väldigt långsam maskin - det finns flera stora paket som redan erbjuds förkompilerade av denna anledning, det är inte obligatoriskt att kompilera allt -. Jag kan inte prata för min flickvän låter mig inte bråka på sin dator, hehe, och min är så bra att jag inte känner något behov av att uppdatera den, men om jag har rätt så tycker jag att det är värt att slösa några minuters sammanställning så att jag kan ha ett skräddarsytt system. Mer anpassad och lämplig för vår maskin tror jag inte att någonting kan uppnås utan att gå in på de där Linux-metoderna från grunden, Linux från grunden, som jag tror redan är reserverade för datavetare eller mycket avancerade Linux-kännare.
Hälsningar.
Mycket bra!
en sak existerar inte "Amd Atom x2"
inte heller kommer det att existera är ett varumärke av intel
gäller