I denne lille guiden skal jeg forklare (og lære deg) hvorfor det er bedre at du kompilerer et program (si Firefox, Vlc, etc) fra kildekoden enn å laste det ned (fra The Software Center, Yumex, Pacman, etc) og installere.
Først går vi med teorien:
Hva er "kompilere"?
Kompilering transformerer kildekoden (kode skrevet på et bestemt programmeringsspråk, si C, C ++, etc.) til et kjørbart program for dets drift ved å bruke prosessoren til å konvertere språket som brukes til å generere koden til binær og samler . Det kalles også ofte emballasje.
Hvorfor er det bedre å "kompilere"?
Først må du vite følgende for å forstå hvorfor. Sagt på en «rå» måte (enkel, ikke veldig profesjonell osv.), Har hvert løp (Pentium, Core, Atom, etc) og dets art (Intel, AMD, ARM, etc.) prosessorer instruksjoner (programvare skrevet i samler som behandler koden) til modellen sin (Core i7, Core i5, Atom x2, Phantom x8, Arm, etc.) og har også generelle instruksjoner som alle i sitt slag har.
Når du laster ned fra repositoriene gjennom Software Center / apt-get / Yumex / Yum / Pacman / etc, sies et program som installeres automatisk å være dette forhåndskompilert for drift på alle mulige prosessorer (Intel og Amd). Siden det er et forhåndskompilert program, går de instruksjonene som er typiske for den spesifikke prosessormodellen tapt (tenk at hvis et program som Firefox eller Chrome, som har mer enn 7 eller 8 millioner linjer med kode, måtte de legge alle de spesifikke instruksjonene for hver prosessor på markedet, ville mengden kode være så stor at det programmet ikke lenger ville være effektivt) og ikke etterlate seg noe mer enn de generelle av skapermerket (Intel, Amd, Arm).
Når du laster ned, pakker ut og kompilerer kildekoden til et program selv, kompilerer den med de spesifikke instruksjonene til TU prosessor, (som ikke betyr at det ikke vil fungere på en maskin med en annen, bare at den vil være optimalisert spesielt og rent for prosessoren din), og dermed frigjøre og frigjøre all kraften som prosessoren din er i stand til å gi takket være de spesifikke instruksjonene.
I mer tekniske detaljer er disse spesifikke instruksjonene nært knyttet til det som er kjent som brikkesettet til hovedkortet ditt, noe som er den store hodepinen for de av oss som har Intel når vi vil oppgradere prosessoren og hovedkortet.
Du vil bli overrasket over kraften som din amd atom x2 eller du Intel Core på innsiden, 2 Core Duo, i3, etc fra din gamle PC. Nå forstår du hvorfor det er mye snakk i Linux-verdenen om å kompilere den berømte kjernen (hjertet til hvert operativsystem)? Tenk deg hvis du kompilerer et helt system (grafisk miljø (Gnome, Kde, etc), Kernel, ofte brukte programmer (Firefox, Vlc, Chrome, Wine, etc.) spesielt for din pc) all hastigheten og optimaliseringsnivået du ville ha.
Dette kompileringsprinsippet for å få en kode som er optimalisert spesielt for maskinen din, er den som brukes av distroer som Gentoo og derivater (som jeg ikke kommer til å snakke om nå, jeg bruker Fedora minimal med kompilering av Gnome 3, kjernen og andre programmer) der systemet, oppdateringene og programmene dine alltid blir samlet.
Ulemper med kompilering:
Jeg har allerede forklart alle fordelene, men som alt i universet har den en imot.
I samlingssaken er de;
- Tiden som trengs for dette (Firefox med en i7 4790K (uten overklokk siden jeg er veldig dårlig med spenninger) tar 3 minutter, Gnome Shell (linjen ikke noe annet) med Gnome-Control-Center tok meg ca 2 minutter, begge ble samlet samtidig i Fedora. Men på en maskin med en mindre kraftig prosessor kan denne tiden være uforholdsmessig lang).
- Prosessoren bruker 100% av kraften med alle kjernene maksimalt, så forbruk og varme skyter i været (ta hensyn til dette hvis du har overklokking eller hvis det er spesielt en bærbar PC), så det er praktisk at du forbereder en kompis eller en kaffe for anledningen.
- Kanskje du mangler et bibliotek (verktøy) som bruker et program slik at det ikke feiler i samlingen. Generelt har alle distroer pakker eller sett med dem for å unngå dette (de kommer pakket med forskjellige biblioteker og andre ting som gjør at kjernen kan kommunisere ordentlig med prosessoren under prosessen).
Hvordan kan jeg kompilere?
Her snakker jeg om å lage et program for normal bruk, ikke en kjerne.
aptitude installere bygg-essensiell dh-make devscripts fakeroot debhelper debian-policy ccache dh-autoreconf autotools-dev build-dep ardor
Jeg setter debian-policy, men hvis distro ikke er Debian og det gir deg en feil om at det ikke finnes noen slik pakke, er det bare å ignorere det. Jeg må avklare at jeg ikke har brukt disse systemene på lang tid, så hvis en pakke ikke lenger er i lagrene, ikke bekymre deg.
For Fedora:
sudo yum -y installer kernel-headerskjerneutviklingsudo yum groupinstall "Utviklingsverktøy"sudo yum groupinstall "Utviklingsbiblioteker"
Her må jeg be om unnskyldning for de som bruker Arch (jeg kjenner ikke distro godt) og OpenSuse, siden jeg ikke kjenner disse distribusjonene eller de respektive pakkene for å utføre en korrekt kompilering (og jeg har ikke bekreftet hva som er på nettverket, slik at for de to vet jeg ikke om de fungerer).
Nå som du har alle nødvendige krav, trenger du bare å laste ned kildekoden til programmet du vil kompilere, i henhold til utvidelsen pakker du den ut ved hjelp av terminalen (ikke bekymre deg, jeg gir deg kommandoene), og når du går til mappen (alltid med terminalen) gjør du det samme følgende:
Hvis du har muligheten til å konfigurere deg selv til å velge komponenter og andre:
./configure
Så skriver du:
make
Og til slutt for å installere programmet på Linux:
make install
Kommandoer for å pakke ut terminalen (filen pakkes ut i en mappe der filen ligger):
.Tar filer (tjære) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Pakke | tar cvf file.tar / file / * Pakk ut | tar xvf file.tar Vis innhold | tjære tvf file.tar
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .tar.gz - .tar.z - .tgz (tjære med gzip) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Pakke og glidelås | tar czvf archive.tar.gz / archive / Pakk ut og pakke ut | tar xzvf file.tar.gz Vis innhold (ikke hentet) | tar tzvf file.tar.gz
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .gz (gzip) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Komprimere | gzip -q-fil (Filen komprimerer og omdøper den til "file.gz") Pakk ut gzip -d file.gz (Filen pakker den ut og etterlater den som "fil" Merk: gzip komprimerer bare filer, ikke kataloger
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .bz2 (bzip2) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Komprimere | bzip2-fil | bunzip2-fil (Filen komprimerer og omdøper den til "file.bz2") bzip2 -d file.bz2 | bunzip2 file.bz2 (Filen pakker den ut og etterlater den som "fil") Merk: bzip2 komprimerer bare filer, ikke kataloger
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .tar.bz2 (tjære med bzip2) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Komprimere | tar -c filer | bzip2> file.tar.bz2 Unzip | bzip2 -dc file.tar.bz2 | tjære -xv | tar jvxf file.tar.bz2 (nylige versjoner av tar) Vis innhold | bzip2 -dc file.tar.bz2 | tjære -tv
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .zip (zip) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Komprimere | zip file.zip / mayo / arkiver Pakk ut | pakke ut file.zip Vis innhold | pakke ut -v file.zip
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .rar (rar) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Komprimere | rar -a file.rar / may / archives Unzip | rar -x file.rar Vis innhold | rar -v file.rar | rar -l file.rar
Og det er alt. Hilsen fra Buenos Aires, Argentina. God ferie og nyttår! :).
Problemet med å kompilere er at det ikke alltid fungerer første gang og er mer kjedelig
Problemet med å kompilere er at med mindre du har en gammel og begrenset PC, vil forbedringene ikke merkes ... vel, kanskje på en datamaskin med intensiv bruk er det et alternativ, men for de fleste brukere er det bare en kjedelig prosess.
Jeg tror det er kjernen i saken. Er ytelsesforbedringen som vil bli merkbar når du pakker pakkene, så viktig at det vil ta tid og problemer med denne oppgaven i bakgrunnen?
Det samme hvis du har en i7-kompilering er det praktisk, fordi det er raskere, og jeg beregner at det fungerer noe bedre. Nå med en pc med intelatom er det ikke praktisk, med mindre du virkelig trenger den ekstra kraften som kompilering gir, men det kan ta timer å kompilere et program med en mindre kraftig prosessor.
Jeg er helt enig, det har skjedd med meg å kompilere og finne ut etter en stund at du mangler et bibliotek, spore det og må møte prosessen igjen ... Det er sjelden at alt fungerer ved første forsøk ... xD
¡Muy interesante!
Hvis du lager et program, hvordan fungerer oppdateringene etterpå? Er de automatiske, eller må vi være klar over om en ny versjon har kommet ut?
Du må oppdatere den manuelt, det vil si å kompilere den nyeste versjonen som er en annen la oss si "ulempe" som det også gjør noe kjedelig
Siden oppdateringer ikke eksisterer, eliminerer faktisk Linux-distribusjoner og deres forskjellige måter å pakke programvaren og de tilsvarende pakkebehandlerne på, ulempene med å kompilere for hver nye oppdatering (og å løse avhengighetene).
Hilsener.
Hvis du kompilerer den ved å laste ned kildekoden fra en hvilken som helst side, må du gjøre det manuelt og lære å installere den, fordi ikke alle er installert likt.
Nå, hvis du har Gentoo eller noen distro med porter, gjør du det nesten automatisk fra lagringsplassene.
I Gentoo tar pakkesjefen din, Portage, seg av oppdateringer og avhengigheter; Jeg vet ikke på andre distros. Selvfølgelig innebærer hver oppdatering åpenbart rekompilering.
Det var en tid da jeg samlet alt jeg kunne. Da ble jeg sliten, spesielt på grunn av tiden jeg måtte bruke maskinen på (45 min for kjernen, 10 min for krom ...) og på grunn av tiden jeg brukte på å fikse problemer som oppstod på farten. I tillegg fant jeg personlig ingen økning i ytelse, jeg hadde følelsen av at alt var det samme. Av disse grunnene bruker jeg nå alt forhåndskompilert, alt er øyeblikkelig og uten konflikter. Selv om jeg lærte mye på den tiden, ville jeg bruke gentoo 🙂
Selv, og det er noe jeg har sett lite på, kan det kompileres fra systemer som apt. Legg til et build-flagg til apt-source og voila. Før det, selvfølgelig, installerer du nødvendige pakker for å utføre kompileringene, hvis ikke, fungerer det ikke ... selv om det er en mer direkte form for kompilering, og det innebærer færre trinn, siden bare første gang det tar opp installasjonen av pakker og det følgende, møtte avhengigheter og pakken som sådan.
Hilsener.
Den har apt-build-funksjonalitet, selv om jeg tror den ikke kompilerer avhengighetene, men installerer forhåndskompilerte binærfiler.
Fra det første øyeblikket jeg så overskriften, kunne jeg ikke unngå å tenke det samme, og etter å ha lest hele den utmerkede artikkelen, har jeg ideen i tankene, går rundt tusen ganger, Gentoo ... Gentoo, hvor er du?
å kompilere er et vidunder, å kunne nyte visse funksjoner og bruke dem er uvurderlig, men tid og "nåværende behov" er unnskyldelige, da de ikke gjelder.
Kanskje trenger vi noe i midten, hvor verken biblioteker eller detaljer i versjonsendring vil kaste bort så mye tid. Vi får se hva som vil skje da, eller hvis vi virkelig bruker oss til å kompilere på selve egnetheten, uprmi og zypper som vi allerede har installert.
3 minutter Firefox! .... Mente du 30?
Dette tok lang tid på pc-en min med en 8350G fx4.5, jeg bruker gentoo.
$ genlop -t Firefox | hale -n3
Lør 6. des 20:00:00 2014 >>> www-client / firefox-34.0.5-r1
sammenslåingstid: 16 minutter og 35 sekunder
Disse instruksjonene som er spesifikke for hver prosessor kalles mnemonics og er fysisk implementert i mikroprosessoren, de er det som utgjør maskinspråket, og kompilerer derfor slik at et program kan kjøres på mange typer mikroprosessorer, hvis eller hvis de må begrenses til minst mulig vanlige minnesmerker støttet av alle disse mikroprosessorer ... kaste bort reell kapasitet til de mest nåværende og kraftige mikroprosessorer.
Slik gjør bedrifter og GNU / Linux binære distroer det.
For meg med en Intel i7 4790K med 18 GB RAM har det tatt meg det jeg sa før
Jeg forstår at mikroen du har er overlegen, men forskjellen er avskyelig, sannheten må være en savanne i den hastigheten. Kanskje det er noe relatert til avhengigheter eller BRUK som er det samme som konfigurasjonsalternativene når du kompilerer for hånd.
Liten detalj som du unngikk for å si 18 GB Ram bortsett fra i7, ikke alle har den maskinen, men du kan gjøre en benchmarking slik at forskjellen blir merkbar, fordi teorien er fin, men la oss se om den kompenserer.
En annen flott detalj, prosessoren er Intel, derfor har den det beste flytpunktet uavhengig av modellen, en veldig relevant funksjon for å utføre denne typen prosesser
Det er sant at kompilering er kjedelig. Men du lærer mye ved å fornekte deg Makefiles, biblioteker, etc. Det er noe som er bra å gjøre til og med et par ganger. Jeg bruker alt forhåndskompilert av samme grunn som Tanrax siterte.
Hilsener fra Argentina!
Problemet som jeg vanligvis har når jeg prøver å kompilere helt nye versjonsprogrammer, skyldes alltid avhengighetene, noen ganger er det nødvendig å kompilere alle (for å komme til de nyeste versjonene) og deretter tenke på å kunne kompilere det du vil ha.
PATH-problemer og FLAGS er de tingene som fremdeles holder meg fra å ville kompilere alt (selv om jeg vanligvis gjør det slik jeg kan). Et av verktøyene jeg pleier å konsultere for å kunne kompilere avhengighetene er følgende nett - http://www.linuxfromscratch.org/ -
#LinuxFromScratch er et prosjekt som gir "trinnvis" instruksjoner for å kompilere kildekoden du trenger å bruke på systemet ... (98% av det jeg har behov for å kompilere har jeg oppnådd ved å veilede meg herfra og gradvis lære ).
Som et pluss poeng tror jeg at å kompilere et system fra 0 ville være interessant, spesielt for utviklingsmiljøer eller servere, blant annet som vi sier "er vanligvis ikke like foranderlige" som en personlig datamaskin der vi hele tiden installerer og endrer alt (det er mitt synspunkt) i tillegg til at den minste ytelsen som oppnås i denne typen bruksområder er veldig viktig.
Dette er poeng som det blir sagt lite om i dag, og bare "lærde" klarer seg, men det er interessant å gi denne typen opplæringsprogrammer de trenger, slik at vi hver dag finner flere mennesker som bidrar med hjelp til de forskjellige samfunnene der de deltar og ikke bare Gnu / Linux forblir i tide på grunn av dårlig ytelse til samarbeidspartnerne, at selv om det til nå "det har fungert på denne måten" er det ikke veldig sunt å bare ha sluttbrukere.
Tillat meg et lite tillegg. For å oppnå fordelene du presenterer her, må du konfigurere den velkjente make.conf riktig. Prosessorfamilien og kompilasjonsflagg er angitt der. Tilsvarende der kan du spesifisere antall kjerner som skal brukes under kompilering. Når du bruker alle kjernene til mikrofonen din, reduseres kompileringstiden drastisk.
En hilsen
Veldig bra artikkel. Jeg hadde også likt et eksempel, eller jeg vil gjerne ha et innlegg om hvordan du kompilerer i archlinux eller hvordan du bruker AUR. Godt nytt år fra Mendoza.
For lenge siden ... Jeg har alltid samlet kjernen, men det er veldig kjedelig å måtte vente 40 minutter: / uansett ... Jeg har ikke samlet noe bortsett fra videodrivere på lenge (bare for spesielle konfigurasjoner).
Artikkelen er veldig interessant, men nei herre, pakking og kompilering er ikke det samme;) ..
Veldig bra innlegg. Jeg er enig i å kompilere visse programmer, men noen ganger er det litt kjedelig, så det tar maskinen å gjøre prosessen. Men bortsett fra det lærer man mye, spesielt når det er behov for biblioteker eller pakker.
Jeg tror at for Archlinux, for å kompilere, trenger du følgende pakke: base-devel
pacman -S base-utvikling
Informasjonen er veldig bra, men sannheten er at det ikke er nødvendig å kompilere, hvis du er en standardbruker og bare vil at noe skal fungere slik, ikke berør det engang. Det er kjedelig å kompilere, alltid, jeg sier alltid at du mangler et bibliotek, du finner et eller annet problem, fortell meg å kompilere minecraft-serveren slik at alt er så bra som mulig, og jeg tar deg god tid ... bortsett fra at hver gang en oppdatering eller oppdatering eller hva som helst kommer ut, begynn å kompilere xd igjen
Akkurat, kompilering er for veldig spesifikke programmer du trenger å bruke optimalt, fordi det å samle alt, og som du sier, det alltid er oppdateringer, for det meste rullende utgivelsesdistroer, er irriterende. Jeg vil bare anbefale lts kjerner.
I dag støtter nesten alle prosessorer som folk bruker de samme instruksjonene, og derfor er det bare gunstig å kompilere når det gjelder kjernen og i et system som en server, at, og tydeligvis når det ikke er noen forhåndskompilerte pakker, alt annet det er bortkastet tid.
Bra bidrag, jeg skal prøve å se hvordan det går, så langt installerer jeg (nesten alltid) fra repositoriene ...
Liten observasjon: Rare kommandoalternativer er ikke skrevet og bunzip2 pakker bare ut.
Det mest jeg kompilerte var en kjerne for debian wheezy, og det tok meg ca 2 timer (jeg har en AMD E450 1.6 GHz dual-core CPU), og det er nettopp derfor jeg ikke installerer gentoo, tiden for å kompilere og laste ned hele systemet ville ta meg omtrent 18 timer , og at hvis jeg ikke har noe problem, er det sant at det er bedre å kompilere, men mesteparten av tiden er det tatt for lang tid, og jeg tror det ikke er verdt det. Du har et hastighetsløft, men det er ikke mye, og jeg tror ikke det rettferdiggjør all investert tid. Selv om jeg en dag har en pc med like god prosessor som din, vil jeg prøve å installere gentoo o
Mennesker:
Uten flammeintensjoner eller noe, ser slackere det som naturlig å kompilere, generere binær, installere det med den relevante pakkebehandleren (som løser avhengigheter åpenbart, slapt-get, swaret, slackyd og / eller flere andre), med alt optimalisert for vår team og som ingenting, noe som ikke er noe å skrive hjem om eller kvantefysikk.
Å se på en DVD uten å pusle på en P3 750MHz med 192MB RAM er verken umulig eller vanskelig å oppnå over Slackware. Jeg bekrefter, og det er raskere enn å kompilere en Gentoo. Men det er ikke det samme, jeg bruker også Gentoo.
Forskjellen mellom hacker og forbruker er at forbrukeren sier "Jeg skulle ønske det ville fungere slik" og hackeren "Jeg har en skrutrekker og noen få minutter" - Rael Dornfest
Er det virkelig en merkbar ytelsesforbedring?
Med en siste generasjon i7 og 18 Gb RAM, hvordan merker du forskjellen mellom kompilerte pakker og binære filer?
Jeg har alltid hatet egnetheten til selvkompilerende pakker, men jeg tror at det i dagens skrivebordsmiljø er veldig komplisert å opprettholde det, spesielt på grunn av kompleksiteten i avhengighetene, de kontinuerlige oppdateringene og den enorme avhengigheten av ikke-gratis kilder. , som i tilfelle proprietære drivere, som utvilsomt påvirker ytelsen mye mer enn noe aspekt som kan kompileres ...
Hilsen
Tatt i betraktning at Gnome 3 bare kompilerer det (jeg vil si navnene grovt siden navnene på pakkene jeg ikke husker): skallet (linjen), gnome-control-center (komplett, med sine avhengigheter osv.), Appleten for tiden og omtrent 2 eller 3 avhengigheter for at skallet skal fungere. Åpenbart krevde skallet flere avhengigheter for at alle funksjonene skulle fungere, men det førte meg til å kompilere blant annet GDM, jeg løste dette ved å endre det med GConf når skallet ble kompilert.
Nå når jeg logger på (via terminal), tar miljøet mye mindre tid å laste inn enn da det ble installert forhåndskompilert. Kaster en tid på lufta, på en forhåndskompilert måte, tror jeg det tok omtrent 3 eller 4 sekunder å laste skallet (med omtrent 5 der tapetet vises, jeg forsto aldri hvorfor det tok så lang tid, det virker for meg at det er på grunn av driveren med GT 630) og kompilert så snart jeg skrev inn passordet, starter X org og miljøet er lastet (med forhåndslast og prelink gjorde jeg dem mye raskere, det ser ut til at det er fordi de ble passert til hurtigbufferen; 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 instruksjoner, som ignoreres av generiske builds fra forskjellige distroer (debian compiles for 486, ubuntu for 686) kan gi deg en ide om når maskinvare er bortkastet ved å prøve å spenne en 20 år gammel prosessor - kanskje takk for at du støttet min gamle pentium mmx-. Hvis du trenger "proprietære drivere" som du nevnte, gir kjernen muligheten til å laste spesifikk firmware på kompileringstidspunktet. Ingen flere rare problemer med xorg.
Takk for informasjonen, det er alltid bra å lære (eller lære på nytt) (:
Debian gjerne til Gentoo 🙂
http://crysol.org/es/node/699
En annen ulempe er at samlingen av terminal er for brukere som kjenner eller allerede har kunnskap om Linux. Er det et grafisk verktøy som ikke administrerer kompilering, installasjon og oppdatering av programmer, men grafisk?
Beregn linux gjør det, det er en gentoo med grafiske verktøy klare til å kompilere. I Phoronix anbefaler de det vanligvis.
Jeg er en Linux-bruker, noen ganger når jeg vil installere et program fra depotet, blir de gamle versjonene av programmet installert, rett og slett fordi de nye ikke er kompilert for distro i spørsmålet, tror jeg det er viktig å vite hvordan man skal kompilere, enda mer når de brukes sjeldne distroer.
Alt det står i innlegget er greit, og jeg tviler ikke på at det er sant, men ytelsesforskjellen mellom å installere en binær pakke og å kompilere deg selv er umerkelig for en bruker.
Og ulempene ved å kompilere er mange, og hvis de er tydelig merkbare for brukeren. Derfor går jeg personlig sammen.
Der jeg har lagt merke til mest ytelse når jeg kompilerer kjernen, var det på en bærbar PC med en AMD 64-prosessor. Endringen mellom fabrikkjernen og den kompilerte var brutal.
Akkurat nå har jeg en fabrikkjern på systemet mitt, for som de sier mye her, var det en tid da jeg samlet nesten alt, og jeg ble lei.
Akkurat nå samler jeg bare noen svært viktige programmer, for eksempel å bruke en liten server, eller å spille med emulatorer. For ikke lenge siden laget jeg et innlegg om hvordan jeg kan kompilere mame-versjonen. Disse programmene er vanligvis merkbare når du har optimalisert det for systemet ditt.
Jeg trenger bare å prøve den gentoo distroen, og se hvordan forestillingen går.
Jeg glemte å legge til, for folk som tar lang tid å kompilere kjernen, mer enn 30 minutter, er det flere triks for å gjøre det på kortere tid.
Et av disse triksene er at bare kompilere modulene til utstyret ditt, maksimalt, kanskje maksimalt 70 moduler, er det som ser ut for deg, og hvis vi legger til støtten fra iptables med alle kravene, tror jeg det vil øke til 300 moduler. Kom igjen, det er mye bedre enn å kompilere 3000 oddemoduler, en figur som for tiden kjører hvis kjernemodulene blir samlet slik de kommer fra fabrikken eller som de sier, vanilje.
Programmet som hjelper deg å vite hvilke moduler kjernen for øyeblikket gjenkjenner på systemet ditt er "localmodconfig" eller ved å bruke dette skriptet "streamline_config.pl" som finnes i kjernekildekatalogen, i banen "/ scripts / kconfig / »
Selvfølgelig må du sørge for at alle USB-enhetene er koblet til, siden når kjernen gjenkjenner alle modulene dine, er det bare å kompilere.
Kjernen vil være veldig lett og det vil føles en viss friskhet i systemet, i tillegg til at det gir raskere oppstart og nedleggelse av systemet.
Hilsener.
Livet er ikke så lett! det er programmer som bruker cmake eller andre ting, og det tar tid å holde alt oppdatert og samlet. Og med en slik CPU, hvilken forskjell vil det gjøre for deg?
Problemet med å kompilere er at noen av programmene vi installerer med den metoden senere ikke blir avinstallert eller gir feil når du gjør det, så vi kan ikke avinstallere dem.
Du må lagre mappen med de kompilerte kildene. Når du vil avinstallere, er alt du trenger å gjøre å gå til kildemappen og fra en terminal som root utfører:
# gjør avinstallering
Selvfølgelig er pakkene som er samlet for hånd som standard i hver seriøs distro installert separat, det vil si i / usr / local / bin ikke i / usr / bin der distribusjonens pakkeleder setter dem som standard. er flettet sammen.
Artikkelen reiser flere interessante ting, men mangler en forferdelig kvalitet i sine termer og logiske struktur.
«I et kjørbart program for dets drift ved bruk av PROCESSOR for konvertering av språket som brukes til å generere koden til binæren og samleren. Det kalles også ofte emballasje. "
Falsk . brukes faktisk er en kompilator ansvarlig for å overføre instruksjonene til et bestemt programmeringsspråk til det tilsvarende på monteringsspråk og deretter oversette dette til maskinspråk.
Monteringsspråk er et minnesmerke som gjenspeiler en gruppe instruksjoner bosatt i registerene til brikken.
"Når du laster ned, pakker ut og kompilerer kildekoden til et program selv, blir det samlet med de spesifikke instruksjonene til prosessoren din"
Når du kompilerer et program, vil det ganske enkelt gjøres med instruksjonene som er felles for arkitekturen. Det er opp til hver bruker å aktivere de tilsvarende kompilatorflaggene for å optimalisere et program for en bestemt prosessor.
Angående hva du kommenterer for å kompilere kjernen:
Når du kompilerer kjernen, ser du etter å aktivere eller deaktivere funksjoner som kanskje eller ikke kan være nyttige på et bestemt tidspunkt, noe som ikke nødvendigvis vil gjenspeiles i størrelses- og hastighetsforholdet i utførelsesbelastningen.
Når du refererer til følgende avsnitt:
dh-make devscripts fakeroot debhelper debian-policy ccache dh-autoreconf autotools-dev build-dep
Disse programmene er ikke essensielle for å lage et program. Som du prøvde å si i begynnelsen, forhindrer antall programmeringsspråk deg i å vite helt sikkert hvilke verktøy du må ha installert for å kunne kompilere programmer i GNU / Linux ... du kan vite det bare ved å konsultere dokumentasjonen til programmet du vil gjennomføre. Programmene du nevner, brukes til å DEBIANISERE og pakke i dette formatet et program som kanskje eller ikke kan bli samlet.
Det er andre spørsmål i artikkelen som viser seg å være noe tvetydige i måten de blir presentert på. Det ville være vanskelig å adressere dem alle.
Jeg foreslår gjennomgang av artikkelen så langt som mulig av skaperen og oppfordrer til en bedre kontroll av kvaliteten på publikasjonene.
Mann, det er ikke det heller.
Artikkelen er ikke for Science magazine, den er rett og slett en innledende artikkel, og jeg tror at i de vilkårene den er skrevet, er den grundig nok for en nybegynner å forstå nøkkelbegrepene.
Hvis vi blir akademiske, ville tre fjerdedeler av det som blir publisert på internett, absolutt ingenting verdt.
La oss ikke være så puristiske ... det er umulig å være 100% enig i en artikkel, men vi kan ikke kontinuerlig vurdere "teknisk" kvalitet, som om vi vurderer en doktorgrad.
Min fulle støtte til forfatteren av denne artikkelen
interessant artikkel
Det er alltid bra for frihetselskere å bruke unar i stedet for rar for å pakke ut rars fritt. ( https://packages.debian.org/jessie/unar )
Jeg traff feilen med dette problemet ... Jeg begynte å søke på google, men jeg finner ikke en veiledning for å kompilere firefox under ubunto 14.04 amd64 bits ... ellers får jeg kjernen med følgende opplæring: http://www.redeszone.net/2014/11/28/como-instalar-el-ultimo-kernel-de-linux-en-ubuntu-14-04-lts/
god artikkel, jeg lærer mye. men jeg vil bare bruke dette til et bestemt program som bruker mye ressurser, som for eksempel videoredigerere. Hilsen.
Mellom denne artikkelen og den fra Gentoo de publiserte for noen dager siden, frister de meg til å installere Gentoo på PCen min. For mange år siden brukte jeg Sabayon, som lette hele installasjonsprosessen, men beholdt basen som skal kompileres fra kilden. Jeg kan ærlig talt ikke huske at jeg hadde lagt merke til noen forskjell i ytelsen til den bærbare datamaskinen min (den gangen jeg hadde en runde) med Sabayon eller med Ubuntu, så jeg vet ikke om jeg skal kaste meg alt arbeidet med å slette min Arch som fungerer veldig bra for å installere den. Jeg er ikke sikker på at noen få millisekunder per program er verdt det.
Av de 4 stk med gentoo som jeg har installert og oppdatert, er notatblokken som hadde archlinux lagt til ... Systemd trøtt meg, jeg måtte allerede bruke den med startx fordi i den siste oppdateringen skjøt begge kjernene til 85% av bruken, uten å gjøre ingenting, jeg undersøkte, og det ser ut til at noe har endret seg i systemd for å gjøre slim gal og spise mikroprosessoren.
Nok, det var nok med bue ... for lenge holdt det, mer enn to år, nå installerer jeg gentoo, jeg går for test3-oppdateringen, for i kveld vil en openbox med frites gå.
God artikkel, det gir meg lyst til å kompilere Qupzilla, men med et sempron vil det ta dager, vel, jeg vet ikke så mye, men det gir fortsatt et dårlig resultat.
En annen ulempe med samlingen er at når det er en oppdatering, er det nødvendig å kompilere og installere oppdateringen på nytt, noe som er et problem med tanke på at noen programmer har korte utviklingssykluser, og for dem blir oppdateringer utgitt ofte, 2 til 3 måneder, med alle dette kjeder den uformelle brukeren og den konstante brukeren bruker mye tid på å holde systemet oppdatert.
Jeg vil gjerne vite hvilke applikasjoner som er mer anbefalt å kompilere. i henhold til dets nytte, oppdateringsfrekvens og forbedring av ytelsen.
Dette er absurd. Hvis du trenger å kompilere deg selv, bruker du feil fordeling. Den eneste grunnen til å kompilere er å legge til feilsøkingsalternativer for å redusere farten, i bytte for bedre å fikse andres feil.
Systemet ditt er ikke tregt fordi det trenger -O3, det er tregt fordi det er et program som leser for mye til disken eller maler for mye på skjermen.
Min anbefaling: I stedet for å mikrooptimalisere systemet vårt, la oss jobbe som et fellesskap for å forbedre programvaren som vi alle har.
Du har ikke forklart hvordan du kan optimalisere samlingen, for eksempel i Gentoo BRUK alternativene brukes til å optimalisere den genererte koden, du må også indikere prosessoren, etc. Hvordan gjøres det i UBUNTU / Debian eller Arch?, Interessant artikkel.
Good!
I mangel av å lese kommentarene nedenfor har jeg en nybegynner i Linux:
Jeg bruker Fedora 20, jeg har allerede mange ting installert, for eksempel Firefox-nettleseren, for å kompilere den til maskinen min, kan jeg bare gjøre det? Det vil si under koden og kompilere det, eller må jeg først eliminere programmet som jeg allerede har lastet ned for å kompilere det nye ...
Det samme med Linux-kjernen og slikt….
Kanskje jeg spør om noe absurd, men jeg sier allerede at jeg er ganske nybegynner for de seriøse Linux-tingene lol
En hilsen!
Jeg tror kjernen ikke er nødvendig, men du må opprette en oppføring for hver kjerne i GRUB, med Firefox vet jeg ikke om det anbefales å ha 2 Firefox, personlig foretrekker jeg å ha 1 bare kjerne og 1 bare Firefox
Det eneste jeg har samlet i livet mitt har vært en versjon i utvikling av Musique, jeg liker den appen veldig, den var verdt hele tiden det tok for prosessen. For en sluttbruker som meg følte jeg meg oppfylt når jeg var ferdig.
Hilsen, utmerket blogg.
Hei, jeg bruker Slackware og kompilering av applikasjoner er det mest normale i verden.
Du installerer systemet fra en ISO som allerede er forhåndskompilert, og de forhåndskompilerte applikasjonene du kan bruke fra det offisielle depotet er få, men hvis du vil kan du laste ned kildekoden til systemet (og de originale skriptene som hele distro er kompilert med. ) og komponer det selv, slik jeg forestiller meg at Gentoo fungerer.
Imidlertid gir SlackBuilds-prosjektet skript (som den offisielle distro) for mange tredjepartsapplikasjoner, der du laster ned kildekoden til det du vil installere og konverterer den til en tgz- eller txz-pakke som senere installeres med den. distros offisielle pakkeleder. Derfor er fordelen at du unngår å bruke konfigurere, lage, lage installasjonskommandoer, og du kan oppdatere, installere på nytt eller fjerne pakken som alle andre og veldig enkelt.
Ulempen er at i Slackware blir ikke avhengighetene løst automatisk som i andre distroer, så du må først kompilere de nødvendige avhengighetene og applikasjonen du vil installere sist. De kompilerte programmene jeg bruker er fra LibreOffice, Texmaker, Spyder, Qt5, QtCreator, VLC, Wine, GRASS, QGis, blant andre. Avhengig av applikasjonen og dens krav, kan kompilering og installasjon ta alt fra 5 minutter til flere timer. Men hvis du vil, kan du finne og bruke en ferdig kompilert pakke for å spare deg for tid.
Jeg har ikke hatt tid til å sjekke om det er stor forskjell mellom kompilerte og forhåndskompilerte pakker, men systemet mitt er veldig stabilt. Men jeg tror at det i det minste ikke er så stor forskjell på den bærbare datamaskinen min fordi den ikke er så kraftig, den har en i3-prosessor og 4 GB RAM.
Hilsen og lykke til med å kompilere.
Jeg bruker for øyeblikket Funtoo, for å være ærlig, ser jeg ingen ytelsesforskjell mellom å kompilere et program eller installere den forhåndskompilerte, jeg gjør det utelukkende for et pedagogisk formål, men hvis det er forskjeller mellom å kompilere kjernen og ikke gjøre det, ja . Da jeg brukte debian og ønsket å kompilere noe, brukte jeg følgende sekvens:
. / Konfigurer
Lag -j3 (antall kjerner + 1)
Alien
Den brukte alien fordi den oppretter en binær av det kompilerte programmet, og slik at du kan installere den på systemet ditt som en hvilken som helst binær, og hvis du vil avinstallere, kan du bare bruke synaptic eller en annen pakkebehandling, det er fordelen med å lage pakken og installere pakken som sådan, i stedet for å gjøre "make install"
Jeg ser en forbedring, i det minste med store og tunge pakker, for eksempel tar Libreoffice i Funtoo mye kortere tid å laste inn enn i Debian, det samme har skjedd med VLC eller med mpv og MKV FullHD og multi-lydfiler, belastningen er mye raskere.
En annen som også har gjennomgått forandringen er Firefox, i Debian blir det 10 eller 15 faner med PCen min, men med Funtoo har jeg klart å ha opptil 30 åpne og det fortsetter som om ingenting og forbruket av ram er mye lavere og mindre Har en tendens til å fryse for JS-filer, tror jeg det avhenger mer av konteksten på hvordan bestemte oppgaver og programmer utføres.
Problemet er at når vi laster ned den forhåndskompilerte, gjør vi enhver Linux-distro til en rå kopi av windows
Mer enn en spektakulær økning i ytelse, ser jeg fordelen i muligheten for å kompilere pakkene med komponentene man ønsker: Hvis du for eksempel ikke har en skriver, kan du indikere at pakkene med støtte for CUPS ikke er kompilert - pakkene at de bruker CUPS, selvfølgelig, hvis du kompilerer Hunspell med eller uten CUPS, vil det ikke ha noe å si - bare - i det minste i Gentoo - som indikerer i make.conf-filen, der alle alternativene for å bygge pakker er sentraliserte "-cups"; hvis du bruker KDE5, eller Plasma 5, som de kaller det nå, kan du spesifisere kodene "-kde", "-qt4", som var gyldige koder for KDE 4, men unødvendige i KDE 5 og applikasjoner som ble portet til det nye skrivebordet, "-gnome" , "-Gtk", og så videre med alle komponenter du vet du ikke trenger. Hvis et bestemt program av en eller annen grunn trenger, la oss si GTK, kan du i en fil som heter package.use, indikere at det bruker GTK, for eksempel for Pidgin med samme etikett, men uten minustegnet, det vil si "gtk »:« Net-im / pidgin gtk ».
På denne måten oppnås et system flere hundre megabyte lettere og mindre og mer effektive binærfiler, da det ikke har unødvendig kode. Jeg har gått fra Ubuntu til Gentoo gjennom Opensuse, Kubuntu, Debian, Arch, Chakra eller KaOS, og Gentoo er det raskeste systemet jeg har hatt, og jeg har fortsatt den samme Core 2 Duo som jeg hadde for 7 år siden. Selvfølgelig forlater jeg kompileringene for natten, for det tar for eksempel å ta QT5 flere timer. Hvis du setter parameteren "finhet" for Portage i make.conf, kan du installere pakker eller oppdatere mens du fortsetter å jobbe med maskinen, og du merker knapt mye nedgang, selv om det tydeligvis øker kompileringstiden. men kom igjen, med å sette den til å installere eller oppdatere når jeg går til middag, og om nødvendig la den fungere over natten, fungerer den gamle datamaskinen min bedre enn kjærestens I3 med Kubuntu.
Et annet stadig viktigere aspekt er at når vi kompilerer fra kildefiler, er sikkerheten at pakken vi installerer, den opprinnelige, at den ikke har blitt manipulert av tredjeparter, nesten fullført. Jeg tror Debian implementerer et byggeverifiseringssystem som vil garantere litt mer enn forhåndskompilering vi installerte faktisk kommer fra den opprinnelige kilden, men det vil aldri være så mye sikkerhet når den pakken er blitt samlet på maskinen vår med vårt oppsett.
Etter min mening, med en moderne prosessor, ikke en skralle som min, hehe, og hvis vi vil øke hastigheten på prosessen, med 8 GB RAM for å kunne montere / var / tmp - den midlertidige mappen som Portage bruker til kompilering - i RAM, som alltid vil være raskere enn en harddisk eller en SSD, i dag ser jeg ikke mye mening å bruke forhåndskompilerte pakker. Hvis det tar omtrent 40 minutter å kompilere min Firefox-datamaskin, hvor lang tid kan det ta for en I5 eller en I7 som for øyeblikket er på markedet, 5 minutter, enda mindre? Jeg snakker om kilden firefox, ikke firefox-bin, som er en forhåndskompilert binær pakke som kan installeres på Gentoo hvis du har en veldig treg maskin - det er flere store pakker som allerede tilbys forhåndskompilert av denne grunn, det er ikke obligatorisk å kompilere alt -. Jeg kan ikke snakke fordi kjæresten min ikke lar meg fikle med datamaskinen hennes, hehe, og min går så bra at jeg ikke føler behov for å fornye den, men hvis jeg har rett, synes jeg det er verdt å kaste bort noen minutter kompilering for å få laget et system etter mål. Mer tilpasset og tilpasset maskinen vår, tror jeg ikke at noe kan oppnås uten å gå inn på disse Linux-metodene fra bunnen av, Linux fra bunnen av, som jeg tror allerede er reservert for datavitenskapere eller svært avanserte Linux-kjennere.
Hilsener.
Veldig bra!
en ting eksisterer ikke «Amd Atom x2»
ni existira er et varemerke for Intel
hilsen