In deze kleine gids ga ik uitleggen (en je leren) waarom het beter is dat je een programma compileert (bijvoorbeeld Firefox, Vlc, enz.) Vanuit de broncode, dan het downloadt (uit The Software Center, Yumex, Pacman, enz. ) en installeer.
Eerst gaan we met de theorie:
Wat is "compileren"?
Compileren is het transformeren van de broncode (code geschreven in een bepaalde programmeertaal, bijvoorbeeld C, C ++, etc.) naar een uitvoerbaar programma voor de werking ervan door het gebruik van de processor om de taal die wordt gebruikt om de code te genereren om te zetten in binaire en assembler. Het wordt ook vaak verpakking genoemd.
Waarom is het beter om te "compileren"?
U moet eerst het volgende weten om te begrijpen waarom. Op een «grove» manier gezegd (eenvoudig, niet erg professioneel, enz.), Hebben elk ras (Pentium, Core, Atom, enz.) En zijn soort (Intel, AMD, ARM, enz.) Processor instructies (software geschreven in assembler die de code verwerkt) van hun model (Core i7, Core i5, Atom x2, Phantom x8, Arm, etc.) en hebben ook algemene instructies die al hun soort hebben.
Wanneer u downloadt van de repositories via het Software Center / apt-get / Yumex / Yum / Pacman / etc, zegt een programma dat automatisch installeert dat dit voorgecompileerd voor werking op alle mogelijke processors (Intel en Amd). Omdat het een voorgecompileerd programma is, gaan die instructies die typerend zijn voor dat specifieke processormodel verloren (denk dat als een programma als Firefox of Chrome, die meer dan 7 of 8 miljoen regels code hebben, ze alle specifieke instructies voor elk processor op de markt, zou de hoeveelheid code zo groot zijn dat dat programma niet langer efficiënt zou zijn), waardoor er niets meer overblijft dan de algemene van het merk van de maker (Intel, Amd, Arm).
Wanneer u de broncode van een programma zelf downloadt, unzipt en compileert, wordt het gecompileerd met de specifieke instructies van TU bewerker, (wat niet betekent dat het niet zal werken op een machine met een andere, alleen dat het specifiek en puur voor uw processor geoptimaliseerd zal worden), waardoor al het vermogen wordt ontketend en vrijgegeven dat uw processor kan geven dankzij de specifieke instructies.
In meer technische details zijn deze specifieke instructies nauw verbonden met wat bekend staat als de chipset van je moederbord, wat de grote hoofdpijn is voor degenen onder ons die Intel hebben als we de processor en het moederbord willen upgraden.
Je zou versteld staan van de kracht die je amd atoom x2 of jij Intel Core binnen, 2 Core Duo, i3, etc vanaf uw oude pc. Begrijp je nu waarom er in de Linux-wereld veel gepraat wordt over het compileren van de beroemde Kernel (het hart van elk besturingssysteem)? Stel je voor dat als je een heel systeem compileert (grafische omgeving (Gnome, Kde, etc), Kernel, veelgebruikte programma's (Firefox, Vlc, Chrome, Wine, etc.) speciaal voor je pc) alle snelheid en optimalisatieniveaus die je zou hebben.
Dit compilatieprincipe om een code te verkrijgen die speciaal voor jouw machine is geoptimaliseerd, wordt gebruikt door distributies zoals Gentoo en afgeleiden (waar ik het nu niet over ga hebben, ik gebruik Fedora minimaal met compilatie van Gnome 3, de kernel en andere programma's) waar het systeem, uw updates en uw programma's altijd worden gecompileerd.
Nadelen van compilatie:
Ik heb alle voordelen al uitgelegd, maar zoals alles in het universum heeft het er een tegen.
In het verzamelgeval zijn ze;
- De tijd die hiervoor nodig is (Firefox met een i7 4790K (zonder overklok aangezien ik erg slecht ben met voltages) duurt 3 minuten, Gnome Shell (de balk niets meer) met Gnome-Control-Center kostte me ongeveer 2 minuten, beide worden gecompileerd op dezelfde tijd in Fedora. Maar op een machine met een minder krachtige processor kan deze tijd onevenredig lang zijn).
- De processor gebruikt 100% van zijn vermogen met al zijn kernen maximaal, dus het verbruik en de warmte schieten omhoog (houd hier rekening mee als je overklokt of als het vooral een notebook is), dus is het handig dat je een mate of een koffie zet voor de gelegenheid.
- Misschien mist u een bibliotheek (tool) die een programma gebruikt, zodat deze geen fouten maakt bij de compilatie. Over het algemeen hebben alle distributies pakketten of sets daarvan om dit te vermijden (ze zitten vol met verschillende bibliotheken en andere dingen die de kernel in staat stellen om tijdens het proces naar behoren te communiceren met de processor).
Hoe kan ik compileren?
Hier heb ik het over het compileren van een programma voor normaal gebruik, niet over een kernel.
aptitude install build-essential dh-make devscripts fakeroot debhelper debian-policy ccache dh-autoreconf autotools-dev build-dep ardor
Ik heb debian-policy geplaatst, maar als je distro geen Debian is en je een foutmelding krijgt dat zo'n pakket niet bestaat, negeer het dan gewoon. Ik moet duidelijk maken dat ik deze systemen lange tijd niet heb gebruikt, dus als een pakket niet meer in de repositories staat, maak dan geen probleem.
Voor Fedora:
sudo yum -y installeer kernel-headerskernel-ontwikkelingsudo yum groupinstall "Ontwikkelingstools"sudo yum groupinstall "Development Libraries"
Hier moet ik mijn excuses aanbieden voor degenen die Arch gebruiken (ik ken de distro niet goed) en OpenSuse, aangezien ik deze distributies of de respectievelijke pakketten niet ken om een correcte compilatie uit te voeren (en ik heb niet bevestigd wat er op het netwerk staat, zodat ik voor die twee niet weet of ze werken).
Nu je alle noodzakelijke vereisten hebt, hoef je alleen de broncode te downloaden van het programma dat je wilt compileren, afhankelijk van de extensie die je uitpakt met de terminal (maak je geen zorgen, ik laat je de commando's achter) en wanneer je naar de map gaat (altijd met de terminal) doe je hetzelfde:
Als u de mogelijkheid heeft om uzelf te configureren om de componenten en andere te kiezen:
./configure
Vervolgens typ je:
make
En tot slot om het programma op uw linux te installeren:
make install
Opdrachten om uit te pakken met behulp van de terminal (het bestand wordt uitgepakt in een map waarin het bestand zich bevindt):
.Tar-bestanden (tar) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Pack | tar cvf file.tar / file / * Uitpakken | tar xvf file.tar Bekijk inhoud | tar tvf-bestand.tar
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .tar.gz - .tar.z - .tgz (tar met gzip ) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Pak en ritssluiting | tar czvf file.tar.gz / file / Uitpakken en unzippen | tar xzvf file.tar.gz Bekijk inhoud (niet uitgepakt) | tar tzvf-bestand.tar.gz
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .gz (gzip) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Comprimeren | gzip -q bestand (Het bestand comprimeert en hernoemt het "file.gz") Unzip | gzip -d file.gz (Het bestand pakt het uit en laat het staan als "bestand" Opmerking: gzip comprimeert alleen bestanden, geen mappen
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .bz2 (bzip2) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Comprimeren | bzip2-bestand | bunzip2-bestand (Het bestand comprimeert en hernoemt het "file.bz2") Unzip | bzip2 -d bestand.bz2 | bunzip2 file.bz2 (Het bestand pakt het uit en laat het als "bestand" staan) Opmerking: bzip2 comprimeert alleen bestanden, geen mappen
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .tar.bz2 (teer met bzip2) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Comprimeren | tar -c bestanden | bzip2> file.tar.bz2 Unzip | bzip2 -dc bestand.tar.bz2 | teer -xv | tar jvxf file.tar.bz2 (recente versies van tar) Bekijk inhoud | bzip2 -dc bestand.tar.bz2 | tar -tv
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .zip (zip) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Comprimeren | zip file.zip / mayo / archieven Unzip | unzip file.zip Bekijk inhoud | unzip -v file.zip
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .rar (rar) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Comprimeren | rar -a file.rar / mei / archieven Unzip | rar -x file.rar Bekijk inhoud | rar -v bestand.rar | rar -l bestand.rar
En dat is alles. Groeten uit Buenos Aires, Argentinië. Fijne feestdagen en nieuwjaar! :).
Het probleem met compileren is dat het niet altijd de eerste keer werkt en vervelend is
Het probleem met compileren is dat, tenzij je een oude en beperkte pc hebt, de verbeteringen niet al te opvallen ... nou ja, op een computer met intensief gebruik is het een optie, maar voor de meeste gebruikers is het gewoon een vervelend proces.
Ik denk dat dat de kern van de zaak is: is de prestatieverbetering die merkbaar zal zijn bij het samenstellen van de pakketten zo belangrijk dat het de tijd en het gedoe van deze taak op de achtergrond zou kosten?
Hetzelfde als je een i7-compilatie hebt, het is handig, omdat het sneller is en ik bereken dat het iets beters werkt. Nu met een pc met Intel Atom is het niet handig, tenzij je echt die extra kracht nodig hebt die compileren geeft, maar het kan uren duren om een programma te compileren met een minder krachtige processor.
Ik ben het er helemaal mee eens, het is mij overkomen om te compileren en er na een tijdje achter te komen dat je een bibliotheek mist, deze bijhoudt en het proces opnieuw onder ogen moet zien ... Het komt zelden voor dat alles bij de eerste poging werkt ... xD
¡Muy interesante!
Als je een programma compileert, hoe werken de updates dan achteraf? Zijn ze automatisch of moeten we weten of er een nieuwe versie is uitgekomen?
Je moet het handmatig updaten, dat wil zeggen het compileren van de meest recente versie, dat is een ander, laten we zeggen, "nadeel" waarvoor het ook iets vervelends doet
Aangezien updates niet bestaan, elimineren Linux-distributies en hun verschillende manieren om de software en de bijbehorende pakketbeheerders te verpakken het ongemak van het opnieuw compileren voor elke nieuwe update (en het oplossen van afhankelijkheden).
Groeten.
Als u het compileert door de broncode van een willekeurige pagina te downloaden, moet u dit handmatig doen en leren hoe u het moet installeren, omdat niet alle hetzelfde zijn geïnstalleerd.
Nu, als je Gentoo of een of andere distro met ports hebt, dan doe je dat bijna automatisch vanuit de repositories.
In Gentoo zorgt uw pakketbeheerder, Portage, voor updates en afhankelijkheden; Ik weet het niet op andere distributies. Uiteraard omvat elke update opnieuw compileren.
Er was een tijd dat ik alles verzamelde wat ik kon. Toen werd ik moe, vooral door de tijd die ik aan het werk van de machine moest besteden (45 min voor de pit, 10 min voor chroom…) en door de tijd die ik besteedde aan het oplossen van problemen die zich tijdens de vlucht voordeden. Daarnaast vond ik persoonlijk geen prestatieverhoging, ik had het gevoel dat alles hetzelfde was. Om deze redenen gebruik ik nu alles voorgecompileerd, alles is onmiddellijk en zonder conflicten. Hoewel ik in die tijd veel heb geleerd, wilde ik gentoo 🙂 gebruiken
Zelfs, en het is iets dat ik nog maar weinig heb gezien, kan het worden samengesteld uit systemen als apt. Voeg een build-vlag toe aan apt-source en voila. Natuurlijk, voorafgaand aan dat, het installeren van de nodige pakketten om de compilaties uit te voeren, anders werkt het niet ... hoewel het een meer directe vorm van compilatie is en dat minder stappen vereist, aangezien alleen de eerste keer dat het de installatie in beslag neemt van pakketten en de volgende, de met-afhankelijkheden en het pakket als zodanig.
Groeten.
Het heeft apt-build-functionaliteit, hoewel ik denk dat het de afhankelijkheden niet compileert, maar vooraf gecompileerde binaire bestanden installeert.
Vanaf het eerste moment dat ik de kop zag, kon ik niet anders dan hetzelfde denken, en na het lezen van het hele uitstekende artikel, heb ik het idee in gedachten duizend keer rond te gaan, Gentoo ... Gentoo, waar ben je?
compileren is geweldig, in staat zijn om van bepaalde functies te genieten en ze te gebruiken is onbetaalbaar, maar tijd en "huidige behoeften" zijn niet te verontschuldigen, aangezien het niet van toepassing is.
Misschien hebben we iets in het midden nodig, waar noch bibliotheken, noch details in versiewijzigingen zoveel tijd zullen verspillen. We zullen zien wat er dan zal gebeuren, of of we ons echt inzetten om te compileren op de aptitude, uprmi en zypper die we al hebben geïnstalleerd.
3 minuten firefox!…. Bedoelde je 30?
Dit heeft even geduurd op mijn pc met een 8350G fx4.5, ik gebruik gentoo.
$ genlop -t firefox | tail -n3
Za 6 dec 20:00:00 2014 >>> www-client / firefox-34.0.5-r1
samenvoegingstijd: 16 minuten en 35 seconden
Deze instructies die specifiek zijn voor elke processor worden mnemonics genoemd en worden fysiek geïmplementeerd in de microprocessor, ze vormen de machinetaal, daarom compileren ze zodat een programma op veel soorten microprocessors kan draaien, als en als ze moeten worden beperkt tot de minste hoeveelheid gemeenschappelijke geheugensteuntjes ondersteund door al die microprocessors ... verspilling van echte capaciteit van de meest recente en krachtige microprocessors.
Dit is hoe bedrijven en gnu / linux binaire distributies het doen.
Voor mij met een Intel i7 4790K met 18 GB RAM heeft het me gekost wat ik eerder zei
Ik begrijp dat de micro die je hebt superieur is, maar het verschil is verschrikkelijk, de waarheid moet een savanne zijn met die snelheid. Misschien is het iets gerelateerd aan afhankelijkheden of GEBRUIK die hetzelfde zijn als de configuratie-opties bij het handmatig compileren.
Klein detail dat je overbodig maakte om te zeggen 18GB RAM behalve de i7, niet iedereen heeft die machine, maar je zou een benchmarking kunnen doen, dus het verschil is merkbaar, want de theorie is leuk, maar laten we eens kijken of het compenseert.
Een ander geweldig detail, de processor is Intel, daarom heeft deze de beste drijvende komma onafhankelijk van het model, een zeer relevante functie om dit soort processen uit te voeren
Toegegeven, compileren is vervelend. Maar je leert veel door Makefiles, bibliotheken, enz. Het is iets dat zelfs een paar keer goed is om te doen. Ik gebruik alles voorgecompileerd om dezelfde reden als Tanrax noemde.
Groeten uit Argentinie!
Het probleem dat ik over het algemeen heb als ik probeer volledig nieuwe versieprogramma's te compileren, is altijd te wijten aan afhankelijkheden, soms is het nodig om ze allemaal te compileren (om naar de laatste versies te gaan) en dan na te denken over het kunnen compileren wat je wilt.
PATH-problemen en VLAGGEN zijn de dingen die me er nog steeds van weerhouden om alles te willen compileren (hoewel ik het meestal doe zoals ik kan). Een van de tools die ik meestal raadpleeg om de afhankelijkheden te kunnen compileren, is het volgende web - http://www.linuxfromscratch.org/ -
#LinuxFromScratch is een project dat "stap-voor-stap" instructies biedt om de broncode te compileren die je nodig hebt om op het systeem te gebruiken .. (98% van wat ik nodig heb om te compileren heb ik bereikt door me vanaf hier te begeleiden en geleidelijk aan het leren).
Als een pluspunt denk ik dat het compileren van een systeem vanaf 0 interessant zou zijn, vooral voor ontwikkelomgevingen of servers, onder andere waarvan we zeggen "zijn meestal niet zo veranderlijk" als een personal computer waarin we constant alles installeren en wijzigen (het is mijn mening) naast het feit dat het minimum aan prestaties dat wordt behaald in dit soort gebruikstoepassingen erg belangrijk is.
Dit zijn punten waar tegenwoordig heel weinig over wordt gezegd en alleen de "geleerden" redden het, maar het is interessant om dit soort dingen de tutorials te geven die ze nodig hebben, zodat we elke dag meer mensen vinden die bijdragen aan de verschillende gemeenschappen waar ze aan deelnemen. en niet alleen Gnu / Linux blijft in de tijd vanwege de slechte prestaties van de medewerkers, dat hoewel het tot nu toe "zo heeft gewerkt" het niet erg gezond is om alleen Eindgebruikers te hebben.
Staat u mij een kleine toevoeging toe. Om de voordelen die u hier presenteert te verkrijgen, moet u het bekende make.conf correct configureren. De processorfamilie en compilatievlaggen worden daar aangegeven. Evenzo kunt u daar het aantal kernen specificeren dat tijdens het compileren moet worden gebruikt. Als je alle kernen van je microfoon gebruikt, wordt de compilatietijd drastisch verkort.
groeten
Zeer goed artikel. Ik had ook graag een voorbeeld gehad of ik zou direct een bericht willen hebben over het compileren in archlinux of het gebruik van AUR. Gelukkig nieuwjaar vanuit Mendoza.
Lang geleden ... Ik heb altijd de kernel gecompileerd, maar het is erg vervelend om 40 minuten te moeten wachten: / hoe dan ook ... Ik heb al een hele tijd niets gecompileerd behalve de videostuurprogramma's (alleen voor speciale configuraties).
Het artikel is erg interessant, maar nee meneer, inpakken en compileren is niet hetzelfde;) ..
Zeer goede post. Ik ben het eens met het compileren van bepaalde programma's, maar soms is het een beetje vervelend, dus het kost de machine om het proces uit te voeren. Maar afgezien daarvan leert men veel, vooral als er bibliotheken of pakketten nodig zijn.
Ik denk dat voor Archlinux, om te compileren je het volgende pakket nodig hebt: base-devel
pacman -S basis-devel
De info is erg goed, maar de waarheid is dat het niet nodig is om te compileren, als je een standaardgebruiker bent en je wilt gewoon dat iets zo werkt, raak dat dan niet eens aan. Het is vervelend om te compileren, altijd, ik zeg altijd dat je een bibliotheek mist, dat je een of ander probleem tegenkomt, zeg me dat ik de minecraft-server moet compileren zodat alles zo goed mogelijk is en ik neem je tijd…. behalve dat elke keer dat er een update of patch of wat dan ook uitkomt, xd opnieuw moet compileren
Precies, compileren is voor heel specifieke programma's die je optimaal moet gebruiken, want alles compileren, en zoals je zegt, er zijn altijd updates, meestal rollende release-distro's, is vervelend. Ik zou alleen lts-kernels aanbevelen.
Tegenwoordig ondersteunen bijna alle processors die mensen gebruiken dezelfde instructies, daarom is compileren alleen gunstig als het gaat om de kernel en in een systeem zoals een server, dat, en uiteraard als er geen voorgecompileerde pakketten zijn, al het andere een verspilling van tijd.
Goede bijdrage, ik ga proberen om te zien hoe het gaat, tot nu toe installeer ik meestal (bijna altijd) vanuit de repositories ...
Kleine opmerking: de rar-commando-opties zijn niet-scripted en bunzip2 decomprimeert alleen.
Het maximum dat ik heb gecompileerd was een kernel voor Debian Wheezy en het kostte me ongeveer 2 uur (ik heb een amd e450 1.6 ghz dual-core cpu) en dat is precies waarom ik gentoo niet installeer, de tijd om het geheel te compileren en te downloaden. systeem zou me ongeveer 18 uur kosten, en als ik geen probleem heb, het waar is dat het beter is om te compileren, maar meestal is de tijd te lang en ik denk dat het het niet waard is. Je hebt een snelheidsboost, maar het is niet veel en ik denk niet dat het alle geïnvesteerde tijd rechtvaardigt. Hoewel als ik op een dag een pc heb met een processor die zo goed is als de jouwe, zal ik proberen gentoo 😛 te installeren
Mensen:
Zonder vlamintenties of zoiets, zien slackers het als natuurlijk om te compileren, het binaire bestand te genereren, het te installeren met de relevante pakketbeheerder (dat lost uiteraard afhankelijkheden op, slapt-get, swaret, slackyd en / of verschillende andere), met alles geoptimaliseerd voor onze team en alsof er niets is om over naar huis te schrijven of kwantumfysica.
Een dvd kijken zonder te struikelen op een P3 750MHz met 192MB RAM is niet onmogelijk en ook niet moeilijk te bereiken via Slackware. Ik getuig, en het is sneller dan het samenstellen van een Gentoo. Maar het is niet hetzelfde, ik gebruik ook Gentoo.
Het verschil tussen hacker en consument is dat de consument zegt "Ik wou dat het zo zou werken" en de hacker "Ik heb een schroevendraaier en een paar minuten" - Rael Dornfest
Is er echt een merkbare prestatieverbetering?
Hoe merk je met een laatste generatie i7 en 18 Gb ram het verschil tussen gecompileerde pakketten en binaire bestanden?
Ik heb altijd een hekel gehad aan de geschiktheid van zelf-compilerende pakketten, maar ik denk dat het in de huidige desktopomgeving erg complex is om het vol te houden, vooral vanwege de complexiteit van de afhankelijkheden, de voortdurende updates en de enorme afhankelijkheid van niet-vrije bronnen., zoals in het geval van propriëtaire stuurprogramma's, die ongetwijfeld de prestaties veel meer beïnvloeden dan enig aspect dat kan worden gecompileerd ...
groeten
Gezien het feit dat Gnome 3 het alleen compileert (ik zal de namen grof noemen, aangezien de namen van de pakketten ik niet meer weet): de shell (de balk), gnome-control-center (compleet, met zijn afhankelijkheden, enz.), De applet voor de tijd en ongeveer 2 of 3 afhankelijkheden om de shell te laten werken. Het is duidelijk dat de shell meer afhankelijkheden nodig had om al zijn functies te laten werken, maar het bracht me ertoe onder andere GDM te compileren. Ik loste dit op door het te wijzigen met GConf zodra de shell was gecompileerd.
Als ik me nu aanmeld (via terminal), kost het laden van de omgeving veel minder tijd dan toen het voorgecompileerd was geïnstalleerd. Ik werp een tijd in de lucht, op een voorgecompileerde manier denk ik dat het ongeveer 3 of 4 seconden duurde om de schaal te laden (met ongeveer 5 waarin het behang wordt getoond, heb ik nooit begrepen waarom het zo lang duurde, het lijkt me dat het is vanwege de driver met de GT 630) en gecompileerd zodra ik het wachtwoord invoerde, X org start en de omgeving wordt geladen (met preload en prelink heb ik ze veel sneller gemaakt, het lijkt mij dat het komt omdat ze zijn gepasseerd naar de cache; https://www.google.com.ar/search?q=preload+y+prelink+fedora&ie=utf-8&oe=utf-8&gws_rd=cr&ei=iXaqVPykO4qYNpbTgdAP )
Het feit dat de i7 ss4- en ss3-instructies heeft, die worden genegeerd door generieke builds van verschillende distributies (debian compileert voor 486, ubuntu voor 686), kan je een idee geven van wanneer hardware wordt verspild door te proberen een 20 jaar oude processor te overspannen. - misschien bedankt voor het steunen van mijn oude pentium mmx-. Als je "propriëtaire stuurprogramma's" nodig hebt, zoals je al zei, biedt de kernel de mogelijkheid om specifieke firmware te laden tijdens het compileren. Geen rare problemen meer met xorg.
Bedankt voor de info, het is altijd goed om te leren (of opnieuw te leren) (:
Debian graag aan Gentoo 🙂
http://crysol.org/es/node/699
Een ander nadeel is dat de compilatie per terminal is voor gebruikers die Linux kennen of al enige kennis hebben. Is er een grafische tool die de compilatie, installatie en update van programma's niet maar grafisch beheert?
Calculate linux doet dat, het is een gentoo met grafische tools die klaar zijn om te compileren. In Phoronix bevelen ze het meestal aan.
Ik ben een linux-gebruiker, soms als ik een programma uit de repository wil installeren, worden de oude versies van het programma geïnstalleerd, simpelweg omdat de nieuwe niet zijn gecompileerd voor de distro in kwestie, denk ik dat weten hoe te compileren essentieel is, nog meer wanneer ze zeldzame distro's worden gebruikt.
Alles wat het in de post zegt, is prima en ik twijfel er niet aan dat het waar is, maar het verschil in prestatie tussen het installeren van een binair pakket en het zelf compileren is onmerkbaar voor een gebruiker.
En de nadelen van compileren zijn talrijk en als ze duidelijk waarneembaar zijn voor de gebruiker. Daarom stap ik persoonlijk om te compileren.
Waar ik de meeste prestaties heb opgemerkt bij het compileren van de kernel, was het op een laptop met een AMD 64-processor. De verandering tussen de fabriekskernel en de gecompileerde kernel was bruut.
Op dit moment heb ik een fabriekskernel op mijn systeem, want zoals ze hier veel zeggen, was er een tijd dat ik bijna alles compileerde en ik moe werd.
Op dit moment compileer ik alleen enkele vitaal belangrijke programma's, zoals om een kleine server te gebruiken of om met emulators te spelen. Onlangs heb ik een bericht geplaatst over het compileren van de mame-versie. Deze programma's over het algemeen als je merkt dat je het geoptimaliseerd hebt voor je systeem.
Ik moet gewoon die gentoo distro proberen, en kijken hoe de uitvoering gaat.
Ik vergat toe te voegen, aan mensen die er lang over doen om de kernel te compileren, meer dan 30 minuten, dat er verschillende trucs zijn om het in minder tijd te doen.
Een van die trucs is dat, alleen het compileren van de modules van je apparatuur, maximaal, misschien hoogstens 70 modules is wat je lijkt en als we de ondersteuning van iptables met al zijn vereisten toevoegen, ik denk dat het zou toenemen tot 300 modules. Kom op, het is veel beter dan 3000 en een beetje modules compileren, een cijfer dat momenteel werkt als de kernelmodules worden gecompileerd zoals het uit de fabriek komt of zoals ze zeggen, vanille.
Het programma dat u zal helpen te weten welke modules de kernel momenteel op uw systeem herkent, is "localmodconfig" of door gebruik te maken van dit script "streamline_config.pl" gevonden in de kernel source directory, in het pad "/ scripts / kconfig /»
Zorg er natuurlijk voor dat al je USB-apparaten zijn aangesloten, want zodra de kernel al je modules herkent, is het alleen een kwestie van compileren.
De pit zal erg licht zijn en je zult een zekere frisheid in het systeem voelen en het opstarten en afsluiten van het systeem versnellen.
Groeten.
Het leven is niet zo eenvoudig! er zijn programma's die cmake of andere dingen gebruiken, en het kost tijd om alles up-to-date en gecompileerd te houden. En wat voor verschil zal het voor u maken als u zo'n CPU heeft?
Het probleem met compileren is dat sommige van de programma's die we met die methode installeren, niet worden verwijderd of fouten geven wanneer we dit doen, dus we kunnen ze niet verwijderen.
U moet de map met de gecompileerde bronnen opslaan, als u de installatie ongedaan wilt maken, hoeft u alleen maar naar de map bronnen te gaan en vanaf een terminal als root uit te voeren:
# maak deïnstallatie
Natuurlijk worden de pakketten die standaard met de hand worden gecompileerd in elke serieuze distro apart geïnstalleerd, dat wil zeggen in / usr / local / bin niet in / usr / bin waar de pakketbeheerder van de distro ze standaard plaatst, zo. Niets is met elkaar verweven.
Het artikel werpt een aantal interessante dingen op, maar het mist een vreselijke kwaliteit in termen en logische structuur.
«In een uitvoerbaar programma voor zijn werking door de PROCESSOR te gebruiken voor de conversie van de taal die wordt gebruikt om de code te genereren naar het binaire bestand en de assembler. Het wordt ook vaak verpakking genoemd. "
Vals. daadwerkelijk wordt gebruikt, is een compiler verantwoordelijk voor het doorgeven van de instructies van een bepaalde programmeertaal aan de corresponderende assembleertaal en vertaalt deze vervolgens in machinetaal.
Assembly-taal is een geheugensteuntje dat een groep instructies weergeeft die in de registers van de chip zijn opgeslagen.
"Wanneer u de broncode van een programma zelf downloadt, decomprimeert en compileert, wordt het samengesteld volgens de specifieke instructies van UW processor"
Bij het compileren van een programma gebeurt dit gewoon met de instructies die gemeenschappelijk zijn voor de architectuur.Het hangt van elke gebruiker af om de overeenkomstige compilervlaggen te activeren om een programma voor een specifieke processor te optimaliseren.
Met betrekking tot wat je zegt over het compileren van de kernel:
Wanneer u de kernel compileert, wilt u functies activeren of deactiveren die op een bepaald moment al dan niet nuttig kunnen zijn, wat niet noodzakelijkerwijs wordt weerspiegeld in de verhouding tussen grootte en snelheid tijdens het laden van de uitvoering.
Wanneer u naar de volgende sectie verwijst:
dh-make devscripts fakeroot debhelper debian-policy ccache dh-autoreconf autotools-dev build-dep
Deze programma's zijn niet essentieel voor het samenstellen van een programma. Zoals je in het begin probeerde te zeggen, verhindert het aantal programmeertalen dat je zeker weet welke tools je geïnstalleerd moet hebben om programma's in gnu / linux te kunnen compileren ... dat kun je alleen weten door de documentatie van het programma dat u wilt uitvoeren. De programma's die u noemt, worden gebruikt om een programma te DEBIANISEREN en in dat formaat te verpakken dat al dan niet gecompileerd kan worden.
Er zijn andere problemen in het artikel die enigszins dubbelzinnig blijken te zijn in de manier waarop ze worden gesteld. Het zou moeilijk zijn om ze allemaal aan te pakken.
Ik stel voor om het artikel zo veel mogelijk door de maker te laten beoordelen en pleit voor een betere controle van de kwaliteit van de publicaties.
Man, dat is het ook niet.
Het artikel is niet voor het tijdschrift Science, het is slechts een inleidend artikel en ik geloof dat het in de termen waarin het is geschreven diep genoeg is voor een beginnende gebruiker om de belangrijkste concepten te begrijpen.
Als we academisch worden, zou driekwart van wat op internet wordt gepubliceerd, absoluut niets waard zijn.
Laten we niet zo puristisch zijn ... het is onmogelijk om het 100% eens te zijn met een artikel, maar we kunnen de "technische" kwaliteit niet continu beoordelen, alsof we een doctoraat evalueren.
Mijn volledige steun aan de auteur van dit artikel
interessant artikel
Het is altijd goed voor liefhebbers van vrijheid om unar te gebruiken in plaats van rar om rars vrijelijk uit te pakken. ( https://packages.debian.org/jessie/unar )
Ik heb de bug met dit probleem getroffen ... Ik ben begonnen met zoeken in Google, maar ik kan geen tutorial vinden om firefox te compileren onder ubunto 14.04 amd64 bits ... anders krijg ik vanavond de kernel met de volgende tutorial: http://www.redeszone.net/2014/11/28/como-instalar-el-ultimo-kernel-de-linux-en-ubuntu-14-04-lts/
goed artikel, ik leer veel. maar ik zou dit alleen gebruiken voor een specifiek programma dat veel bronnen gebruikt, zoals video-editors bijvoorbeeld. Vriendelijke groeten.
Tussen dit artikel en dat van Gentoo die ze een paar dagen geleden publiceerden, verleidden ze me om Gentoo op mijn pc te installeren. Vele jaren geleden heb ik Sabayon gebruikt, die het hele installatieproces vergemakkelijkte, maar de basis behield om vanaf de bron te compileren. Ik kan me eerlijk gezegd niet herinneren dat ik enig verschil heb opgemerkt in de prestaties van mijn laptop (op dat moment had ik een ronde) met Sabayon of met Ubuntu, dus ik weet niet of ik mezelf al het werk moet geven om mijn Arch te verwijderen die heel goed werkt om het te installeren. Ik weet niet zeker of een paar milliseconden per programma het waard zijn.
Van de 4 pc's met gentoo die ik heb geïnstalleerd en geüpdatet, is de notebook met archlinux toegevoegd ... Het systeem had me moe, ik moest het al gebruiken met startx omdat in de laatste update beide cores tot 85% van het gebruik schoten, zonder niets te doen, was ik aan het onderzoeken en het lijkt erop dat er iets is veranderd in systemd om slim gek te maken en de microprocessor op te eten.
Genoeg, het was genoeg met boog ... te lang hield het vast, meer dan twee jaar, nu installeer ik gentoo, ik ga voor de stage3 testupdate, want vanavond gaat er een open doos met frietjes.
Goed artikel, het zorgt ervoor dat ik Qupzilla wil compileren, maar met een sempron duurt het dagen, nou, ik weet niet zo lang, maar het geeft nog steeds een slechte indruk.
Een ander nadeel van de compilatie is dat wanneer er een update is, het nodig is om de update opnieuw te compileren en te installeren, wat een probleem is aangezien sommige programma's korte ontwikkelingscycli hebben en voor hen regelmatig updates worden uitgegeven, 2 tot 3 maanden, met alle hierdoor raakt de toevallige gebruiker verveeld en de constante gebruiker verbruikt veel tijd om zijn systeem up-to-date te houden.
Ik zou graag willen weten welke applicaties het meest worden aanbevolen om te compileren. volgens het nut, de updatefrequentie en de prestatieverbetering.
Dit is absurd, als je jezelf moet compileren, gebruik je de verkeerde distributie. De enige reden om te compileren is om foutopsporingsopties toe te voegen om u te vertragen, in ruil voor het beter oplossen van de bugs van anderen.
Uw systeem is niet traag omdat het -O3 nodig heeft, het is traag omdat een programma te veel op schijf leest of te veel schildert op het scherm.
Mijn aanbeveling: in plaats van ons systeem te micro-optimaliseren, laten we als gemeenschap werken aan het verbeteren van de software die we allemaal hebben.
Je hebt niet uitgelegd hoe je de compilatie kunt optimaliseren, bijvoorbeeld in Gentoo worden USE-opties gebruikt om de gegenereerde code te optimaliseren, je moet ook de processor aangeven, enz. Hoe wordt dat gedaan in UBUNTU / Debian of Arch?, Interessant artikel.
Goed zo!
Omdat ik de onderstaande opmerkingen niet heb gelezen, heb ik een nieuweling in linux:
Ik gebruik Fedora 20, ik heb al heel wat dingen geïnstalleerd, bijvoorbeeld de Firefox-browser, om het voor mijn machine te compileren, kan ik het zonder verder oponthoud doen?, Dat wil zeggen, onder de code en compileren, of moet ik moet ik eerst het programma verwijderen dat ik al heb gedownload om het nieuwe te compileren ...
Hetzelfde met de Linux-kernel en zo….
Misschien vraag ik iets absurds, maar ik heb al gezegd dat ik nogal een newbie ben voor serieuze Linux-dingen lol
Groeten!
Ik denk dat de kernel niet nodig is, maar je moet een vermelding voor elke kernel in GRUB maken, met firefox weet ik niet of het wordt aanbevolen om 2 firefox te hebben, persoonlijk geef ik er de voorkeur aan om 1 alleen kernel en 1 alleen firefox te hebben
Het enige dat ik in mijn leven heb gecompileerd, is een versie in ontwikkeling van Musique, ik vind die app echt leuk, het was alle tijd die nodig was voor het proces waard. Voor een eindgebruiker zoals ik voelde ik me vervuld toen ik klaar was.
Groeten, uitstekende blog.
Hallo, ik gebruik Slackware en het compileren van de applicaties is de normaalste zaak van de wereld.
Je installeert het systeem vanaf een reeds voorgecompileerde ISO en er zijn maar weinig voorgecompileerde applicaties die je kunt gebruiken vanuit de officiële repository, maar als je wilt kun je de broncode van het systeem downloaden (en de originele scripts waarmee de hele distro is gecompileerd ) en compileer het zelf en dat is hoe ik me voorstel dat Gentoo werkt.
Het SlackBuilds-project biedt echter scripts (vergelijkbaar met de officiële distro) voor veel toepassingen van derden, waarin u de broncode downloadt van wat u wilt installeren en deze converteert naar een tgz- of txz-pakket dat er later mee wordt geïnstalleerd. officiële pakketbeheerder van de distro. Daarom is het voordeel dat u de configure, make, make install-opdrachten vermijdt en dat u het pakket net als elk ander en heel gemakkelijk kunt bijwerken, opnieuw installeren of verwijderen.
Het nadeel is dat afhankelijkheden niet automatisch worden opgelost in Slackware zoals in andere distributies, dus je moet eerst de benodigde afhankelijkheden compileren en de applicatie die je als laatste wilt installeren. De programma's die ik gecompileerd gebruik, zijn onder andere van LibreOffice, Texmaker, Spyder, Qt5, QtCreator, VLC, Wine, GRASS, QGis. Afhankelijk van de applicatie en de vereisten, kan het compileren en installeren 5 minuten tot enkele uren duren. Maar als u wilt, kunt u een vooraf samengesteld pakket vinden en gebruiken om uzelf tijd te besparen.
Ik heb geen tijd gehad om te controleren of er veel verschil is tussen gecompileerde en voorgecompileerde pakketten, maar mijn systeem is erg stabiel. Maar ik denk dat er in mijn laptop in ieder geval niet veel verschil is, want hij is niet zo krachtig, hij heeft een i3-processor en 4 GB RAM.
Groeten en veel succes bij het samenstellen.
Ik gebruik momenteel Funtoo, om eerlijk te zijn zie ik geen prestatieverschil tussen het compileren van een programma of het installeren van het voorgecompileerde programma, ik doe het puur voor een educatief doel, maar als er verschillen zijn tussen het compileren van de kernel en het niet doen, ja . Toen ik debian gebruikte en iets wilde compileren, gebruikte ik de volgende volgorde:
. / Configure
Merk -j3 (aantal kernen + 1)
Vreemd
Ik heb alíen gebruikt omdat het een binair bestand van het gecompileerde programma aanmaakt en je het dus op je systeem kunt installeren als elk binair bestand, en dus, als je de installatie ongedaan wilt maken, kun je eenvoudig synaptic of een andere pakketbeheerder gebruiken, dat is het voordeel van het maken van het pakket en het pakket als zodanig installeren, in plaats van "make install" te doen
Ik zie wel een verbetering, in ieder geval met grote en zware pakketten, Libreoffice in Funtoo kost bijvoorbeeld veel minder tijd om te laden dan in Debian, hetzelfde is mij overkomen met VLC of met mpv en MKV FullHD en multi-audiobestanden, de laden is veel sneller.
Een andere die ook de verandering heeft ondergaan, is Firefox, in Debian wordt het hebben van 10 of 15 tabbladen met mijn pc een marteling, maar met Funtoo ben ik erin geslaagd om er tot 30 open te hebben en het gaat door alsof er niets is en het ram-verbruik is veel lager en minder Omdat ik JS-bestanden neigt te bevriezen, denk ik dat het meer afhangt van de context van hoe bepaalde taken en programma's worden uitgevoerd.
Het probleem is dat wanneer we het voorgecompileerd downloaden, we elke linux-distro veranderen in een ruwe kopie van Windows
Meer dan in een spectaculaire prestatieverhoging zie ik het voordeel in de mogelijkheid om de pakketten te compileren met de componenten die men wil: als je bijvoorbeeld geen printer hebt kun je aangeven dat de pakketten met ondersteuning voor CUPS niet gecompileerd zijn -de pakketten die ze gebruiken CUPS, uiteraard, als je Hunspell compileert met of zonder CUPS maakt het niet uit- alleen - in ieder geval in Gentoo- aangeven in het make.conf bestand, waar alle opties voor het bouwen van pakketten gecentraliseerd zijn "-cups "; als je KDE5 of Plasma 5 gebruikt, zoals ze het nu noemen, kun je de tags "-kde", "-qt4" specificeren, die geldige tags waren voor KDE 4 maar niet nodig in KDE 5 en toepassingen die naar het nieuwe bureaublad zijn overgezet, "-gnome", "-Gtk", enzovoort met elk onderdeel waarvan u weet dat u het niet nodig hebt. Als een specifiek programma om wat voor reden dan ook GTK nodig heeft, dan kun je in een bestand met de naam package.use aangeven dat het wel GTK gebruikt, bijvoorbeeld voor Pidgin met hetzelfde label maar zonder het minteken, dat wil zeggen " gtk »:« Net-im / pidgin gtk ».
Op deze manier wordt een systeem bereikt dat honderden megabytes lichter en kleiner en efficiënter is, omdat het geen onnodige code heeft. Ik ben van Ubuntu naar Gentoo gegaan via Opensuse, Kubuntu, Debian, Arch, Chakra of KaOS, en Gentoo is het snelste systeem dat ik heb gehad, en ik heb nog steeds hetzelfde Core 2 Duo dat ik 7 jaar geleden had. Natuurlijk laat ik de compilaties voor de nacht liggen, want het compileren van QT5 duurt bijvoorbeeld enkele uren. Als je de "niceness" parameter voor Portage in make.conf instelt, kun je pakketten installeren of updaten terwijl je doorgaat met de machine en je merkt nauwelijks veel vertraging, hoewel de compilatietijd uiteraard toeneemt; maar kom op, met het installeren of updaten als ik uit eten ga, en indien nodig 's nachts laten werken, werkt mijn oude computer beter dan de I3 van mijn vriendin met Kubuntu.
Een ander steeds belangrijker aspect is dat bij het compileren vanuit bronbestanden de beveiliging dat het pakket dat we installeren het originele is, dat het niet door derden is gemanipuleerd, bijna compleet is. Ik denk dat Debian een build-verificatiesysteem implementeert dat een beetje meer garandeert dat de precompilatie die we installeren daadwerkelijk van de originele bron komt, maar er zal nooit zoveel zekerheid zijn wanneer dat pakket met onze setup op onze machine is gecompileerd.
Naar mijn mening, met een moderne processor, geen ratel zoals de mijne, hehe, en, als we het proces willen versnellen, met 8 GB RAM om / var / tmp te kunnen mounten - de tijdelijke map die Portage gebruikt voor compilatie in RAM, wat altijd sneller zal zijn dan een harde schijf of een SSD, vandaag zie ik niet veel nut in het gebruik van voorgecompileerde pakketten. Als mijn Firefox-computer ongeveer 40 minuten nodig heeft om te compileren, hoe lang kan het dan duren voor een I5 of een I7 die momenteel op de markt zijn, 5 minuten of zelfs minder? Ik heb het over source firefox, niet firefox-bin, wat een voorgecompileerd binair pakket is dat op Gentoo geïnstalleerd kan worden als je een erg trage machine hebt - er zijn verschillende grote pakketten die om deze reden al voorgecompileerd worden aangeboden, dat is het niet verplicht om alles te compileren -. Ik kan niet praten omdat mijn vriendin me niet met haar computer laat spelen, hehe, en de mijne gaat zo goed dat ik niet de behoefte voel om hem te vernieuwen, maar als ik gelijk heb, denk ik dat het de moeite waard is om te verspillen een paar minuten compileren om een systeem op maat te laten maken. Meer aangepast en aangepast aan onze machine, ik denk niet dat er iets kan worden bereikt zonder vanaf het begin in te gaan op die Linux-methoden, Linux helemaal opnieuw, waarvan ik denk dat het al gereserveerd is voor computerwetenschappers of zeer geavanceerde Linux-experts.
Groeten.
Zeer goed!
één ding bestaat niet de «Amd Atom x2»
ni existira is een handelsmerk van intel
groeten