I denne lille guide vil jeg forklare (og lære dig) hvorfor det er bedre, at du kompilerer et program (f.eks. Firefox, Vlc osv.) Ud fra dets kildekode end at downloade det (fra The Software Center, Yumex, Pacman osv.) Og installere.
Først går vi med teorien:
Hvad er "kompilering"?
Kompilering omdanner kildekoden (kode skrevet på et bestemt programmeringssprog, siger C, C ++ osv.) Til et eksekverbart program til dets drift ved hjælp af processoren til at konvertere det sprog, der bruges til at generere koden til binær og samler . Det kaldes også ofte emballage.
Hvorfor er det bedre at "kompilere"?
Først skal du vide følgende for at forstå hvorfor. Sagt på en "rå" måde (enkel, ikke særlig professionel osv.), Har hver race (Pentium, Core, Atom osv.) Og dens art (Intel, AMD, ARM osv.) Af processoren instruktioner (software skrevet i samler, der behandler koden) for deres model (Core i7, Core i5, Atom x2, Phantom x8, Arm osv.) og har også generelle instruktioner, som alle af deres slags har.
Når du downloader fra arkiverne via Software Center / apt-get / Yumex / Yum / Pacman / etc, siger et program, der installeres automatisk, at dette forkompileret til dets drift i alle mulige processorer (Intel og Amd). Da det er et forudkompileret program, går disse instruktioner, der er typiske for den specifikke processormodel, tabt (tænk, at hvis et program som Firefox eller Chrome, som har mere end 7 eller 8 millioner linier kode, måtte de lægge alle de specifikke instruktioner til hver processor på markedet, ville mængden af kode være så stor, at dette program ikke længere ville være effektivt) og efterlade intet mere end de generelle af dets skabermærke (Intel, Amd, Arm).
Når du downloader, dekomprimerer og kompilerer kildekoden til et program selv, kompileres det med de specifikke instruktioner fra TU processor, (hvilket ikke betyder, at det ikke fungerer på en maskine med en anden, kun at det vil blive optimeret specifikt og rent til din processor)frigør og frigør al den magt, som din processor er i stand til at give takket være dens specifikke instruktioner.
I mere tekniske detaljer er disse specifikke instruktioner tæt knyttet til det, der kaldes chipsættet på dit bundkort, hvilket er den store hovedpine for dem af os, der har Intel, når vi vil opgradere processoren og bundkortet.
Du vil blive overrasket over den kraft, som din amd atom x2 eller dig Intel Core inde, Core 2 Duo, i3osv. fra din gamle pc. Forstår du nu, hvorfor der er en masse snak i Linux-verdenen om at kompilere den berømte Kernel (hjertet i hvert operativsystem)? Forestil dig, hvis du kompilerer et helt system (grafisk miljø (Gnome, Kde osv.), Kernel, almindeligt anvendte programmer (Firefox, Vlc, Chrome, Vin osv.) Specielt til din pc) alt det niveau af hastighed og optimering, du ville have.
Dette kompileringsprincip for at opnå en kode, der er optimeret specielt til din maskine, er den, der bruges af distroer som Gentoo og derivater (som jeg ikke vil tale om nu, jeg bruger Fedora minimal med kompilering af Gnome 3, kernen og andre programmer) hvor systemet , dine opdateringer og dine programmer er altid samlet.
Ulemper ved kompilering:
Jeg har allerede forklaret alle fordelene, men som alt i universet har det en imod.
I kompilationssagen er de det;
- Den nødvendige tid til dette (Firefox med en i7 4790K (uden overclock, da jeg er meget dårlig med spændinger) tager 3 minutter, Gnome Shell (bjælken intet mere) med Gnome-Control-Center tog mig cirka 2 minutter, begge blev samlet på samme tid i Fedora. Men på en maskine med en mindre kraftig processor kan denne tid være uforholdsmæssigt lang).
- Processoren bruger 100% af sin effekt med alle kernerne maksimalt, så forbrug og varme skyrocket (tag dette i betragtning, hvis du har overclocking, eller hvis det især er en notesbog), så det er praktisk, at du forbereder en kompis eller en kop kaffe til lejligheden.
- Måske mangler du et bibliotek (værktøj), der bruger et program, så det ikke fejler i kompileringen. Generelt har alle distroer pakker eller sæt af dem for at undgå dette (de kommer pakket med forskellige biblioteker og andre ting, der gør det muligt for kernen at kommunikere som den skal med processoren under processen).
Hvordan kan jeg kompilere?
Her taler jeg om at sammensætte et program til normal brug, ikke en kerne.
aptitude installere build-essentiel dh-make devscripts fakeroot debhelper debian-policy ccache dh-autoreconf autotools-dev build-dep ardor
Jeg sætter debian-policy, men hvis din distro ikke er Debian, og det giver dig en fejl, at der ikke findes en sådan pakke, skal du bare ignorere den. Jeg er nødt til at præcisere, at jeg ikke har brugt disse systemer i lang tid, så hvis en pakke ikke længere er i arkiverne, skal du ikke lave et problem.
For Fedora:
sudo yum -y installer kernel-headerskerneudviklingsudo yum groupinstall "Udviklingsværktøjer"sudo yum groupinstall "Udviklingsbiblioteker"
Her er jeg nødt til at undskylde dem, der bruger Arch (jeg kender ikke distro godt) og OpenSuse, da jeg ikke kender disse distroer eller de respektive pakker til at udføre en korrekt kompilering (og jeg har ikke bekræftet, hvad der er på netværket, så at for de to ved jeg ikke, om de fungerer).
Nu hvor du har alle de nødvendige krav, behøver du kun downloade kildekoden til det program, du vil kompilere, afhængigt af udvidelsen, du pakker den ud ved hjælp af terminalen (rolig, jeg giver dig kommandoerne), og når du går til mappen (altid med terminalen) gør du det samme følge:
Hvis du har mulighed for at konfigurere dig selv til at vælge komponenterne og andre:
./configure
Så skriver du:
make
Og endelig for at installere programmet på din linux:
make install
Kommandoer til at pakke ud ved hjælp af terminalen (filen pakkes ud i en mappe, hvor filen er placeret):
.Tar-filer (tjære) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Pakke | tar cvf file.tar / file / * Udpak | tar xvf file.tar Se indhold | tjære tvf file.tar
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .tar.gz - .tar.z - .tgz (tjære med gzip) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Pakke og lynlås | tar czvf file.tar.gz / file / Udpak og udpak | tar xzvf file.tar.gz Se indhold (ikke udpakket) | tar tzvf-fil.tar.gz
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .gz (gzip) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Komprimering | gzip -q fil (Filen komprimerer og omdøber den til "file.gz") Unzip | gzip -d-fil.gz (Filen pakker den ud og efterlader den som "fil" Bemærk: gzip komprimerer kun filer, ikke mapper
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .bz2 (bzip2) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Komprimering | bzip2-fil | bunzip2-fil (Filen komprimerer og omdøber den til "file.bz2") Unzip | bzip2 -d fil.bz2 | bunzip2 file.bz2 (Filen pakker den ud og efterlader den som "fil") Bemærk: bzip2 komprimerer kun filer, ikke mapper
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .tar.bz2 (tjære med bzip2) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Komprimering | tar -c filer | bzip2> file.tar.bz2 Unzip | bzip2 -dc-fil.tar.bz2 | tjære -xv | tar jvxf file.tar.bz2 (nyere versioner af tar) Se indhold | bzip2 -dc-fil.tar.bz2 | tjære -tv
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .zip (zip) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Komprimering | zip file.zip / mayo / arkiver Unzip | unzip file.zip Se indhold | unzip -v file.zip
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .rar (rar) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Komprimering | rar -a file.rar / may / archives Unzip | rar -x file.rar Se indhold | rar -v file.rar | rar -l file.rar
Og det er alt. Hilsen fra Buenos Aires, Argentina. God jul og nytår! :).
Problemet med kompilering er, at det ikke altid fungerer første gang og er mere kedeligt
Problemet med kompilering er, at medmindre du har en gammel og begrænset pc, vil forbedringerne ikke være for mærkbare ... ja måske på en computer med intensiv brug er det en mulighed, men for de fleste brugere er det bare en kedelig proces.
Jeg tror, det er kernen i sagen. Er den forbedring af ydeevnen, der vil være mærkbar, når pakkerne sammensættes, så vigtige, at det tager tid og besvær med denne opgave i baggrunden?
Det samme, hvis du har en i7-kompilering, er det praktisk, fordi det er hurtigere, og jeg beregner, at det fungerer noget bedre. Nu med en pc med Intel-atom er det ikke praktisk, medmindre du virkelig har brug for den ekstra strøm, som kompilering giver, men det kan tage timer at kompilere et program med en mindre kraftig processor.
Jeg er helt enig, det er sket for mig at kompilere og efter et stykke tid finde ud af, at du mangler et bibliotek, sporer det og bliver nødt til at stå over for processen igen ... Det er sjældent, at alt fungerer ved første forsøg ... xD
Meget interessant!
Hvis du sammensætter et program, hvordan fungerer opdateringerne derefter? Er de automatiske, eller skal vi være opmærksomme på, om en ny version er kommet ud?
Du skal opdatere det manuelt, det vil sige at kompilere den nyeste version, det er en anden, lad os sige "ulempe", som det også gør noget kedeligt for
Da opdateringer ikke eksisterer, eliminerer Linuxdistributioner og deres forskellige måder at pakke softwaren og de tilsvarende pakkeadministratorer faktisk ulejligheden ved at kompilere for hver ny opdatering (og løse afhængighederne).
Greetings.
Hvis du kompilerer det ved at downloade kildekoden fra en hvilken som helst side, skal du gøre det manuelt og lære at installere det, fordi ikke alle er installeret ens.
Nu, hvis du har Gentoo eller noget distro med porte, så gør du det næsten automatisk fra arkiverne.
I Gentoo tager din pakkehåndterer, Portage, sig af opdateringer og afhængigheder; Jeg ved det ikke på andre distroer. Selvfølgelig involverer hver opdatering naturligvis rekompilering.
Der var en tid, hvor jeg samlede alt, hvad jeg kunne. Derefter blev jeg træt, især på grund af den tid, jeg måtte afsætte maskinen, der arbejdede (45 min. For kernen, 10 min. For krom ...) og på grund af den tid, jeg brugte på at løse problemer, der opstod i farten. Derudover fandt jeg personligt ikke en stigning i ydeevnen, jeg havde en fornemmelse af, at alt var det samme. Af disse grunde bruger jeg nu alt forudkompileret, alt er øjeblikkeligt og uden konflikter. Selvom jeg lærte meget på det tidspunkt, ville jeg bruge gentoo 🙂
Selv, og det er noget, jeg har set lidt, det kan kompileres fra systemer som apt. Føj et build-flag til apt-source og voila. Forud for det installerer de nødvendige pakker for at udføre kompileringerne, ellers fungerer det ikke ... selvom det er en mere direkte form for kompilering, og det involverer færre trin, da det kun første gang det er installationen af pakker og det følgende, opfyldt afhængigheder og pakken som sådan.
Greetings.
Det har apt-build-funktionalitet, selvom jeg tror, at det ikke kompilerer afhængighederne, men installerer prækompilerede binære filer.
Fra det første øjeblik, jeg så overskriften, kunne jeg ikke lade være med at tænke det samme, og efter at have læst hele den fremragende artikel har jeg ideen i tankerne, gå tusind gange rundt, Gentoo ... Gentoo, hvor er du?
at kompilere er vidunderligt, at være i stand til at nyde visse funktioner og bruge dem er uvurderlig, men tid og "nuværende behov" er uundgåelige, da de ikke gælder.
Måske har vi brug for noget i midten, hvor hverken biblioteker eller detaljer i versionændring spilder så meget tid. Vi vil se, hvad der vil ske, eller hvis vi virkelig anvender os til at kompilere på selve egnetheden, uprmi og zypper, som vi allerede har installeret.
3 minutter firefox! .... Mente du 30?
Dette tog et stykke tid på min pc med en 8350G fx4.5, jeg bruger gentoo.
$ genlop -t Firefox | hale -n3
Lør 6 dec 20:00:00 2014 >>> www-client / firefox-34.0.5-r1
fletid: 16 minutter og 35 sekunder
Disse instruktioner, der er specifikke for hver processor, kaldes mnemonics og er fysisk implementeret i mikroprocessoren. De er det, der udgør maskinsproget, og kompilerer derfor, så et program kan køre på mange typer mikroprocessorer, hvis eller hvis de skal begrænses til den mindste almindelige mindesmærker understøttet i alle disse mikroprocessorer ... spilder reel kapacitet hos de mest aktuelle og kraftfulde mikroprocessorer.
Det er sådan, virksomheder og GNU / Linux binære distroer gør det.
For mig med en Intel i7 4790K med 18 GB RAM har det taget mig, hvad jeg sagde før
Jeg forstår, at den mikro, du har, er overlegen, men forskellen er uhyggelig, sandheden skal være en savanne i den hastighed. Måske er det noget relateret til afhængigheder eller USE'er, der er de samme som konfigurationsindstillingerne, når man kompilerer manuelt.
Lille detalje, som du undgik for at sige 18 GB Ram bortset fra i7, ikke alle har den maskine, men du kunne lave en benchmarking, så forskellen er mærkbar, fordi teorien er god, men lad os se, om den kompenserer.
En anden stor detalje, processoren er Intel, derfor har den det bedste flydepunkt uafhængigt af modellen, en meget relevant funktion til at udføre denne type proces
Sandt nok er kompilering kedelig. Men du lærer meget ved at gentage dig Makefiles, biblioteker osv. Det er noget, der er godt at gøre selv et par gange. Jeg bruger alt prækompileret af samme grund, som Tanrax citerede.
Hilsner fra Argentina!
Det problem, jeg generelt har, når jeg prøver at kompilere helt nye versionsprogrammer, skyldes altid afhængigheder, nogle gange er det nødvendigt at kompilere dem alle (for at komme til de nyeste versioner) og derefter tænke på at kunne kompilere det, du ønsker.
PATH-problemer og FLAGS er de ting, der stadig forhindrer mig i at ønske at kompilere alt (selvom jeg normalt gør det som jeg kan). Et af de værktøjer, som jeg normalt konsulterer for at kunne kompilere afhængighederne, er følgende web - http://www.linuxfromscratch.org/ -
#LinuxFromScratch er et projekt, der giver "trin for trin" instruktioner til at kompilere den kildekode, du har brug for på systemet ... (98% af det, jeg har brug for til at kompilere, har jeg opnået ved at guide mig selv herfra og gradvist lære).
Som et pluspunkt tror jeg, at kompilering af et system fra 0 ville være interessant især for udviklingsmiljøer eller servere, blandt andet som vi siger "ikke normalt er så udskiftelige" som en personlig computer, hvor vi konstant installerer og ændrer alt (det er mit synspunkt) ud over det faktum, at den mindste ydeevne, der opnås i denne type anvendelsesapplikationer, er meget vigtig.
Dette er punkter, som meget lidt siges i dag, og kun "lærde" klarer, men det er interessant at give denne slags ting de tutorials, de har brug for, så vi hver dag finder flere mennesker, der bidrager med hjælp til de forskellige samfund, hvor de deltager og ikke kun Gnu / Linux forbliver i tide på grund af samarbejdspartnernes dårlige ydeevne, at selv om det indtil nu "det har fungeret på denne måde" er det ikke særlig sundt at have kun slutbrugere.
Tillad mig en lille tilføjelse. For at opnå de fordele, du udsætter her, skal du konfigurere det velkendte make.conf korrekt. Processorfamilien og kompilationsflag er angivet der. På samme måde kan du angive antallet af kerner, der skal bruges under kompilering. Når du bruger alle kernerne i din mikrofon, reduceres kompileringstiden drastisk.
hilsener
Meget god artikel. Jeg ville også have ønsket et eksempel, eller jeg ville gerne have et indlæg om, hvordan man kompilerer i archlinux, eller hvordan man bruger AUR. Godt nytår fra Mendoza.
For længe siden ... Jeg har altid samlet kernen, men det er meget kedeligt at skulle vente 40 minutter: / alligevel ... Jeg har ikke samlet noget undtagen videodrivere i lang tid (kun til specielle konfigurationer).
Artiklen er meget interessant, men nej herre, pakning og kompilering er ikke den samme;) ..
Meget godt indlæg. Jeg er enig i at sammensætte visse programmer, men nogle gange er det lidt kedeligt, så det tager maskinen at udføre processen. Men bortset fra det lærer du meget, især når du har brug for biblioteker eller pakker.
Jeg tror for Archlinux at have kompilering til følgende pakke: base-devel
pacman -S base-udvikling
Info er meget god, men sandheden er, at det ikke er nødvendigt at kompilere, hvis du er en standardbruger, og du bare vil have noget til at fungere som dette, skal du ikke engang røre ved det. Det er kedeligt at kompilere, altid, jeg siger altid, at du mangler et bibliotek, du løber ind i et eller andet problem, fortæl mig at kompilere minecraft-serveren, så alt er så godt som muligt, og jeg tager din tid .... bortset fra at hver gang en opdatering eller patch eller hvad der kommer ud, skal du begynde at kompilere xd igen
Præcis er kompilering til meget specifikke programmer, som du skal bruge optimalt, fordi kompilering af alt, og som du siger, der er altid opdateringer, for det meste rullende frigivelsesdistroer, er irriterende. Jeg vil kun anbefale lts kerner.
I dag understøtter næsten alle processorer, som folk bruger, de samme instruktioner, og derfor er kompilering kun gunstig, når det kommer til kernen og i et system som en server, at og selvfølgelig, når der ikke er nogen forud kompilerede pakker, alt andet det er spild af tid.
Godt bidrag, jeg vil prøve at se, hvordan det går, indtil videre installerer jeg det meste af tiden (næsten altid) fra arkiverne ...
Lille observation: De sjældne kommandomuligheder er ikke-skrevet og bunzip2 udpakkes kun.
Det mest jeg kompilerede var en kerne til debian wheezy, og det tog mig ca. 2 timer (jeg har en AMD e450 1.6 GHz dual-core cpu), og det er netop derfor, jeg ikke installerer gentoo, tiden til at kompilere og downloade hele systemet ville tage mig omkring 18 timer , og at hvis jeg ikke har noget problem, er det rigtigt, at det er bedre at kompilere, men det meste af tiden er det taget for lang tid, og jeg synes, det er ikke det værd. Du har et hastighedsforøg, men det er ikke meget, og jeg tror, det retfærdiggør ikke al den investerede tid. Selvom jeg en dag har en pc med en så god processor som din, vil jeg prøve at installere gentoo 😛
Mennesker:
Uden flammeintentioner eller noget ser slackere det som naturligt at kompilere, generere binærprogrammet, installere det med den relevante pakkehåndterer (der løser naturligvis afhængigheder, slapt-get, swaret, slackyd og / eller flere andre), med alt optimeret til vores team og som om intet, hvilket ikke er noget at skrive hjem om eller kvantefysik.
At se en DVD uden at snuble på en P3 750MHz med 192MB RAM er hverken umulig eller vanskelig at opnå over Slackware. Jeg vidner, og det er hurtigere end at sammensætte en Gentoo. Men det er ikke det samme, jeg bruger også Gentoo.
Forskellen mellem hacker og forbruger er, at forbrugeren siger "Jeg ville ønske, det ville fungere på den måde", og hackeren "Jeg har en skruetrækker og et par minutter" - Rael Dornfest
Er der virkelig en mærkbar præstationsforbedring?
Med en sidste generation i7 og 18 Gb RAM, hvordan bemærker du forskellen mellem kompilerede pakker og binære filer?
Jeg har altid hadet egnetheden af selvkompilerende pakker, men jeg tror, at det i nuværende desktop-miljøer er meget komplekst at opretholde det, især på grund af afhængighedernes kompleksitet, de kontinuerlige opdateringer og den enorme afhængighed af ikke-gratis kilder. , som i tilfælde af proprietære drivere, der utvivlsomt påvirker ydeevnen meget mere end noget andet aspekt, der kan kompileres ...
hilsen
I betragtning af at Gnome 3 kun kompilerer det (jeg vil sige navnene groft, da navnene på pakkerne jeg ikke kan huske): shell (bjælken), gnome-control-center (komplet med dets afhængigheder osv.), Appleten til tiden og ca. 2 eller 3 afhængigheder for, at skallen fungerer. Det er klart, at skallen krævede flere afhængigheder for, at alle dens funktioner kunne fungere, men det fik mig til at kompilere GDM blandt andre, jeg fik dette rettet ved at ændre det med GConf, når skallen blev kompileret.
Nu når jeg logger ind (via terminal), tager miljøet meget kortere tid at indlæse end da det blev installeret prækompileret. At kaste et stykke tid i luften på en forudkompileret måde tror jeg, at det tog cirka 3 eller 4 sekunder at indlæse skallen (med ca. 5, hvor tapetet vises, jeg forstod aldrig, hvorfor det tog så lang tid, det ser ud til, at det er på grund af føreren GT 630) og kompileret, så snart jeg indtastede adgangskoden X org starter, og miljøet er indlæst (med forudindlæsning og prelink gjorde jeg dem meget hurtigere, det ser ud til, at det er fordi de blev sendt til 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, at i7 har ss4- og ss3-instruktioner, som ignoreres af generiske builds fra forskellige distroer (debian-kompiler til 486, ubuntu til 686) kan give dig en idé om, hvornår hardware spildes ved at prøve at spænde over en 20 år gammel processor - måske tak for at støtte min gamle pentium mmx-. Hvis du har brug for "proprietære drivere" som du nævnte, giver kernen mulighed for at indlæse specifik firmware på kompileringstidspunktet. Ikke flere underlige problemer med xorg.
Tak for informationen, det er altid godt at lære (eller genlære) (:
Debian med glæde til Gentoo 🙂
http://crysol.org/es/node/699
En anden ulempe er, at terminalens kompilering er til brugere, der kender eller allerede har en vis viden om Linux. Er der et grafisk værktøj, der ikke styrer kompilering, installation og opdatering af programmer, men grafisk?
Beregn linux gør det, det er en gentoo med grafiske værktøjer klar til at kompilere. I Phoronix anbefaler de det normalt.
Jeg er en Linux-bruger, nogle gange når jeg vil installere et program fra arkivet, installeres de gamle versioner af programmet, simpelthen fordi de nye ikke er kompileret til den pågældende distro, tror jeg, at det er vigtigt at vide, hvordan man kompilerer, endnu mere når de bruges sjældne distroer.
Alt, hvad der står i indlægget, er fint, og jeg er ikke i tvivl om, at det er sandt, men forskellen i ydeevne mellem installation af en binær pakke og kompilering af dig selv er umærkelig for en bruger.
Og ulemperne ved kompilering er mange, og hvis de tydeligt er synlige for brugeren. Derfor går jeg personligt ind for at kompilere.
Hvor jeg har bemærket mest ydelse ved kompilering af kernen, var den på en bærbar computer med en AMD 64-processor. Ændringen mellem fabrikskernen og den kompilerede var brutal.
Lige nu har jeg en fabrikskerne på mit system, for som de siger meget her, var der en tid, hvor jeg samlede næsten alt, og jeg blev træt.
Lige nu kompilerer jeg kun nogle meget vigtige programmer, som f.eks. At bruge en lille server eller at spille med emulatorer. For ikke længe siden lavede jeg et indlæg om, hvordan man kompilerer mame-versionen. Disse programmer generelt, hvis de er mærkbare, når du har det optimeret til dit system.
Jeg skal bare prøve den gentoo distro og se, hvordan forestillingen går.
Jeg glemte at tilføje, til folk, der tager lang tid at kompilere kernen, mere end 30 minutter, er der flere tricks til at gøre det på kortere tid.
Et af disse tricks er, at det kun er kompilering af modulerne til dit udstyr, maksimalt, måske højst 70 moduler, der ser ud til dig, og hvis vi tilføjer understøttelsen af iptables med alle dets krav, tror jeg det ville øges til 300 moduler. Kom nu, det er meget bedre end at kompilere 3000 ulige moduler, en figur, der i øjeblikket fungerer, hvis kernemodulerne er kompileret, som de kommer fra fabrikken eller som de siger, vanilje.
Det program, der hjælper dig med at vide, hvilke moduler kernen i øjeblikket genkender på dit system er "localmodconfig" eller ved at bruge dette script "streamline_config.pl", der findes i kernekildekataloget, i stien "/ scripts / kconfig / »
Sørg selvfølgelig for, at du har tilsluttet alle dine USB-enheder, da når kernen genkender alle dine moduler, er det kun et spørgsmål om kompilering.
Kernen vil være meget lys, og du vil føle en vis friskhed i systemet såvel som hurtigere opstart og nedlukning af systemet mere.
Greetings.
Livet er ikke så let! der er programmer, der bruger cmake eller andre ting, og det tager tid at holde alt opdateret og samlet. Og med en sådan CPU, hvilken forskel vil det gøre for dig?
Problemet med kompilering er, at nogle af de programmer, vi installerer med den metode, derefter ikke afinstalleres eller giver fejl, når vi gør det, så vi kan ikke afinstallere dem.
Du skal gemme mappen med de kompilerede kilder. Når du vil afinstallere, skal du bare gå til kildemappen og fra en terminal som root udfører:
# gør afinstallation
Naturligvis er pakkerne, der er kompileret manuelt som standard i enhver seriøs distro, installeret separat, det vil sige i / usr / local / bin ikke i / usr / bin, hvor distributionspakkehåndteringen placerer dem som sådan. intet er sammenflettet.
Artiklen rejser flere interessante ting, men mangler en forfærdelig kvalitet i dens vilkår og logiske struktur.
«I et eksekverbart program til dets drift gennem brug af PROCESSOR til konvertering af det sprog, der bruges til at generere koden til binæren og samleren. Det kaldes også ofte emballage. "
Falsk . en kompilator faktisk bruges, har den ansvaret for at videregive instruktionerne til et bestemt programmeringssprog til det tilsvarende samlingssprog og derefter oversætte dette til maskinsprog.
Samlingssprog er et husnemonik, der afspejler en gruppe instruktioner, der er bosiddende i chipens registre.
"Når du downloader, dekomprimerer og kompilerer kildekoden til et program selv, kompileres det med den specifikke instruktion fra DIN processor"
Når du sammensætter et program, gøres det simpelthen med de instruktioner, der er fælles for arkitekturen. Det afhænger af hver bruger at aktivere de tilsvarende kompilatorflag for at optimere et program til en bestemt processor.
Med hensyn til hvad du kommenterer ved kompilering af kernen:
Når du kompilerer kernen, søger du at aktivere eller deaktivere funktioner, der måske eller måske ikke er nyttige på et bestemt tidspunkt, hvilket ikke nødvendigvis afspejles i størrelses- og hastighedsforholdet i udførelsesbelastningen.
Når du henviser til følgende afsnit:
dh-make devscripts fakeroot debhelper debian-policy ccache dh-autoreconf autotools-dev build-dep
Disse programmer er ikke essentielle for kompilering af et program. Som du prøvede at sige i begyndelsen, forhindrer antallet af programmeringssprog dig i at vide med sikkerhed, hvilke værktøjer du skal have installeret for at kunne kompilere programmer i gnu / linux ... du kan vide det kun ved at konsultere dokumentationen til det program, du vil udføre. De programmer, du nævner, bruges til at DEBANISERE og pakke i det format et program, der måske eller måske ikke kompileres.
Der er andre spørgsmål i artiklen, der viser sig at være noget tvetydige i den måde, de er opstillet på. Det ville være vanskeligt at adressere dem alle.
Jeg foreslår gennemgang af artiklen så vidt muligt af dens skaber og opfordrer til en bedre kontrol af publikationernes kvalitet.
Mand, det er heller ikke det.
Artiklen er ikke til videnskabsmagasinet, det er simpelthen en indledende artikel, og jeg tror, at det i de termer, som det er skrevet, er dybt nok til, at en nybegynder bruger kan forstå nøglebegreberne.
Hvis vi bliver akademiske, ville tre fjerdedele af det, der offentliggøres på internettet, absolut intet værd.
Lad os ikke være så puristiske ... det er umuligt at være 100% enig med en artikel, men vi kan ikke løbende vurdere den "tekniske" kvalitet, som om vi vurderede en doktorgrad.
Min fulde støtte til forfatteren af denne artikel
interessant artikel
Det er altid godt for frihedselskere at bruge unar i stedet for rar til at pakke rars frit ud. ( https://packages.debian.org/jessie/unar )
Jeg ramte fejlen med dette problem ... Jeg begyndte at søge i google, men jeg kan ikke finde en tutorial til at kompilere firefox under ubunto 14.04 amd64 bits ... ellers får jeg i aften kernen med følgende tutorial: http://www.redeszone.net/2014/11/28/como-instalar-el-ultimo-kernel-de-linux-en-ubuntu-14-04-lts/
god artikel, jeg lærer meget. men jeg vil kun bruge dette til et specifikt program, der bruger mange ressourcer, som f.eks. videoredigerere. Hilsen.
Mellem denne artikel og den fra Gentoo, de offentliggjorde for et par dage siden, frister de mig til at installere Gentoo på min pc. For mange år siden brugte jeg Sabayon, som lettede hele installationsprocessen, men holdt basen, der skal kompilere, fra kilden. Jeg kan ærligt talt ikke huske at have bemærket nogen forskel i ydelsen på min bærbare computer (på det tidspunkt havde jeg et skød) med Sabayon eller med Ubuntu, så jeg ved ikke, om jeg skal kaste mig alt det arbejde med at slette min Arch, der fungerer meget godt for at installere den. Jeg er ikke sikker på, at et par millisekunder pr. Program er det værd.
Af de 4 pc'er med gentoo, som jeg har installeret og opdateret, tilføjes den bærbare computer, der havde archlinux .... Systemd træt mig, jeg var allerede nødt til at bruge den med startx, fordi begge kerner i den sidste opdatering skød til 85% af brugen uden at gøre intet, jeg undersøgte, og det ser ud til, at noget har ændret sig i systemd for at gøre slim gå amok og spise mikroprocessoren.
Nok, det var nok med arch .... for længe det varede, mere end to år, nu installerer jeg gentoo, jeg går til stage3 testopdatering, til i aften vil en openbox med fries gå.
God artikel, det får mig til at ønske at kompilere Qupzilla, men med et sempron vil det tage dage, ja, jeg ved ikke så meget, men det giver stadig en dårlig følelse.
En anden ulempe ved kompilering er, at når der er en opdatering, er det nødvendigt at kompilere og installere opdateringen igen, hvilket er et problem i betragtning af at nogle programmer har korte udviklingscyklusser, og for dem udsendes opdateringer ofte, 2 til 3 måneder, med alt dette keder den afslappede bruger sig, og den konstante bruger bruger meget tid på at holde sit system opdateret.
Jeg vil gerne vide, hvilke applikationer der er mere anbefalet at kompilere. i henhold til dets anvendelighed, opdateringsfrekvens og forbedring af ydeevnen.
Dette er absurd, hvis du har brug for at kompilere dig selv, bruger du den forkerte distribution. Den eneste grund til at kompilere er at tilføje fejlfindingsmuligheder for at bremse dig, til gengæld for bedre at rette andres fejl.
Dit system er ikke langsomt, fordi det har brug for -O3, det er langsomt, fordi der er noget program, der læser for meget til disken eller maler for meget på skærmen.
Min anbefaling: I stedet for at mikrooptimere vores system, lad os arbejde som et samfund for at forbedre den software, som vi alle har.
Du har ikke forklaret, hvordan kompilering optimeres, for eksempel i Gentoo BRUG indstillinger bruges til at optimere den genererede kode, du skal også angive processoren osv. Hvordan gøres det i UBUNTU / Debian eller Arch?, Interessant artikel.
Godt!
I mangel af at læse kommentarerne nedenfor har jeg en nybegynder i linux:
Jeg bruger Fedora 20, jeg har allerede installeret en hel del ting, for eksempel Firefox-browseren, til at kompilere det til min maskine, kan jeg gøre det uden videre?, Det vil sige under koden og kompilere det, eller skal jeg først slette det program, der allerede har Jeg har downloadet for at kompilere den nye ...
Det samme med Linux-kernen og sådan….
Måske spørger jeg noget absurd, men jeg siger allerede, at jeg er en helt nybegynder til de seriøse Linux-ting lol
Greetings!
Jeg tror, at kernen ikke er nødvendig, men du skal oprette en post for hver kerne i GRUB, med firefox Jeg ved ikke, om det anbefales at have 2 firefox, personligt foretrækker jeg at have 1 kun kernel og 1 kun firefox
Det eneste, jeg har samlet i mit liv, har været en version under udvikling af Musique, jeg kan virkelig godt lide den app, den var værd hele tiden det tog for processen. For en slutbruger som mig følte jeg mig opfyldt, da jeg var færdig.
Hilsner, fremragende blog.
Hej, jeg bruger Slackware og kompilering af applikationerne er den mest normale ting i verden.
Du installerer systemet fra en ISO, der allerede er forudkompileret, og de forudkompilerede applikationer, som du kan bruge fra det officielle arkiv, er få, men hvis du vil, kan du downloade kildekoden til systemet (og de originale scripts, som hele distro er kompileret med) og kompilér det selv, som jeg forestiller mig, at Gentoo fungerer.
Imidlertid leverer SlackBuilds-projektet scripts (svarende til den officielle distro) til mange tredjepartsapplikationer, hvor du downloader kildekoden til det, du vil installere, og konverterer den til en tgz- eller txz-pakke, der senere installeres med den. officiel pakkeleder for distro. Derfor er fordelen, at du undgår at bruge konfigurere, oprette, foretage installationskommandoer, og du kan opdatere, geninstallere eller fjerne pakken som enhver anden og meget let.
Ulempen er, at afhængigheder ikke løses automatisk i Slackware som i andre distroer, så du skal først kompilere de nødvendige afhængigheder og den applikation, du vil installere sidst. De kompilerede programmer, som jeg bruger, er fra LibreOffice, Texmaker, Spyder, Qt5, QtCreator, VLC, Wine, GRASS, QGis, blandt andre. Afhængigt af applikationen og dens krav kan kompilering og installation tage alt fra 5 minutter til flere timer. Men hvis du vil, kan du finde og bruge en præ-kompileret pakke for at spare dig tid.
Jeg har ikke haft tid til at kontrollere, om der er meget forskel mellem kompilerede og prækompilerede pakker, men mit system er meget stabilt. Men jeg tror, at der i det mindste ikke er meget forskel på min bærbare computer, fordi den ikke er så kraftig, den har en i3-processor og 4 GB RAM.
Hilsner og held og lykke med at kompilere.
Jeg bruger i øjeblikket Funtoo, for at være ærlig kan jeg ikke se nogen præstationsforskel mellem at kompilere et program eller installere den forudkompilerede, jeg gør det udelukkende til et uddannelsesmæssigt formål, men hvis der er forskelle mellem at kompilere kernen og ikke gøre det, ja. Da jeg brugte debian og ønskede at kompilere noget, brugte jeg følgende sekvens:
./configure
Lav -j3 (antal kerner + 1)
Alien
Jeg brugte alíen, fordi det opretter en binær af det kompilerede program, og så du kan installere det på dit system som enhver binær, og så hvis du vil afinstallere, kan du bare bruge synaptic eller en anden pakkehåndtering, det er fordelen ved at oprette pakken og installere pakken som sådan, i stedet for at gøre "make install"
Jeg ser en forbedring, i det mindste med store og tunge pakker, for eksempel tager Libreoffice i Funtoo meget mindre tid at indlæse end i Debian, det samme er sket for mig med VLC eller med mpv og MKV FullHD og multi-lydfiler, belastningen er meget hurtigere.
En anden, der også har gennemgået ændringen, er Firefox, i Debian bliver 10 eller 15 faner med min pc tortur, men med Funtoo har jeg formået at have op til 30 åbne, og det fortsætter som om intet og forbruget af ram er meget lavere og mindre En tendens til at fryse til JS-filer, jeg tror, det afhænger mere af konteksten på, hvordan visse opgaver og programmer udføres.
Problemet er, at når vi downloader det forudkompilerede, omdanner vi enhver linux distro til en rå kopi af windows
Mere end i en spektakulær forøgelse af ydeevnen ser jeg fordelen ved muligheden for at kompilere pakkerne med de komponenter, man ønsker: Hvis du f.eks. Ikke har en printer, kan du angive, at pakkerne med support til CUPS ikke er kompileret - pakkerne at de bruger CUPS, selvfølgelig, hvis du kompilerer Hunspell med eller uden CUPS, betyder det ikke - bare i det mindste i Gentoo - hvilket angiver i make.conf-filen, hvor alle mulighederne for at bygge pakker er centraliserede "-cups"; hvis du bruger KDE5 eller Plasma 5, som de kalder det nu, kan du angive tags "-kde", "-qt4", som var gyldige tags for KDE 4, men unødvendige i KDE 5 og applikationer, der blev porteret til det nye skrivebord, "-gnome" , "-Gtk" og så videre med enhver komponent, du ved, du ikke har brug for. Hvis det af en eller anden grund er nødvendigt med et specifikt program, lad os sige GTK, kan du i en fil kaldet package.use angive, at det bruger GTK, for eksempel til Pidgin med samme etiket, men uden minustegnet, det vil sige "gtk »:« Net-im / pidgin gtk ».
På denne måde opnås et system flere hundrede megabyte lettere og mindre og mere effektive binære filer, da det ikke har unødvendig kode. Jeg er gået fra Ubuntu til Gentoo gennem Opensuse, Kubuntu, Debian, Arch, Chakra eller KaOS, og Gentoo er det hurtigste system, jeg har haft, og jeg har stadig den samme Core 2 Duo, som jeg havde for 7 år siden. Selvfølgelig forlader jeg kompileringerne om natten, for det tager f.eks. Flere timer at kompilere QT5. Hvis du indstiller parameteren "pænhed" for Portage i make.conf, kan du installere pakker eller opdatere, mens du fortsætter med at arbejde med maskinen, og du næppe bemærker meget afmatning, selvom kompileringstiden naturligvis øges; men kom igen, med at sætte det til at installere eller opdatere, når jeg går til middag, og hvis det er nødvendigt lade det arbejde natten over, fungerer min gamle computer bedre end min kærestes I3 med Kubuntu.
Et andet stadig vigtigere aspekt er, at når vi kompilerer fra kildefiler, er sikkerheden, at den pakke, vi installerer, den originale, at den ikke er blevet manipuleret af tredjeparter næsten total. Jeg tror, at Debian implementerer et build-verifikationssystem, der vil garantere lidt mere, end den prækompil, vi installerede, faktisk kommer fra den oprindelige kilde, men der vil aldrig være så meget sikkerhed, når den pakke er blevet kompileret på vores maskine med vores opsætning.
Efter min mening med en moderne processor, ikke en skralde som min, hehe, og hvis vi vil fremskynde processen med 8 GB RAM for at kunne montere / var / tmp - den midlertidige mappe, som Portage bruger til kompilering - i RAM, som altid vil være hurtigere end en harddisk eller en SSD, i dag ser jeg ikke meget mening med at bruge forudkompilerede pakker. Hvis min Firefox-computer tager ca. 40 minutter at kompilere, hvor lang tid kan det tage for en I5 eller en I7, der i øjeblikket er på markedet, 5 minutter, endnu mindre? Jeg taler om kilden firefox, ikke firefox-bin, som er en prækompileret binær pakke, der kan installeres på Gentoo, hvis du har en meget langsom maskine - der er flere store pakker, der allerede tilbydes prækompileret af denne grund, det er ikke obligatorisk at kompilere alt -. Jeg kan ikke tale, fordi min kæreste ikke vil lade mig fikle med hendes computer, hehe, og min går så godt, at jeg ikke føler behov for at forny den, men hvis jeg har ret, synes jeg det er værd at spilde et par minutter på at kompilere for at have system til mål. Mere tilpasset og tilpasset vores maskine tror jeg ikke, at noget kan opnås uden at gå ind i disse Linux-metoder fra bunden, Linux fra bunden, hvilket jeg synes allerede er forbeholdt computerforskere eller meget avancerede Linux-kendere.
Greetings.
Meget godt!
en enkelt ting findes ikke «Amd Atom x2»
ni existira er et varemærke tilhørende Intel
hensyn