En aquesta petita guia vaig a explicar-los (i ensenyar) perquè és millor que compiles un programa (digui Firefox, Vlc, etc) des de la seva codi font, al fet que el baixis (des del Centre de Programari, yumex, Pacman, etc.) i el instal.
Primer anem amb la teoria:
Què és «compilar»?
Compilar és transformar el codi font (codi escrit en un determinat llenguatge de programació, digui C, C ++, etc.) en un programa executable per al seu funcionament mitjançant l'ús de l'processador per a la conversió de l'llenguatge usat per generar el codi a l'binari i assemblador . També se li sol cridar empaquetament.
Per què és millor «compilar»?
Primer has de saber el següent per entendre el per que. Dit d'una manera «basta» (simple, no molt professional, etc.), cada raça (Pentium, Core, Atom, etc) i la seva espècie (Intel, AMD, ARM, etc) de processador tenen instruccions (programari escrit en assemblador que processa el codi) pròpies del seu model (Core i7, Core i5, Atom x2, Phantom x8, Arm, etc) ia més tenen instruccions generals que tots els de la seva espècie tenen.
Quan vós baixes des dels repositoris a través del Centre de Programari / apt-get / yumex / Yum / Pacman / etc, un programa que s'instal·la de forma automàtica es diu que aquesta precompilat per al seu funcionament en tots els processadors possibles (Intel i Amd). A l'tractar-se d'un programa precompilat es perden aquestes instruccions pròpies de aquest model de processador específic (pensa que si un programa com Firefox o Chrome, que tenen més de 7 o 8 milions de línies de codi, haguessin de posar totes les instruccions específiques per a cada processador que hi ha al mercat, la quantitat de codi seria tan gran que ja no seria eficient aquest programa) deixant-res més que les generals de la seva marca creadora (Intel, Amd, Arm).
A l'baixar, descomprimir i compilar pel teu compte el codi font d'un programa, aquest es compila amb les instruccions específiques de TU processador, (el que no vol dir que no serveixi en una màquina amb un altre de diferent, només que estarà optimitzat específicament i purament per al teu processador), Deslligant i alliberant així tot el poder que el teu processador és capaç de donar gràcies a les seves instruccions específiques.
En detalls més tècnics, aquestes instruccions específiques estan íntimament lligades al que es coneix com el chipset de la teva placa mare, que és el gran maldecap per als que tenim Intel per quan volem fer un upgrade de l'processador i la placa mare.
Et sorprendries de el poder que pot arribar a donar la teva Amd Atom x2 o el teu Intel Core Inside, Core Duo 2, i3, Etc de la teva vella PC. ¿Ara entens per què es parla molt en el món Linux de compilar el famós nucli (cor de tot sistema operatiu)? Imagina't si compilar especialment per al teu pc tot un sistema (entorn gràfic (Gnome, Kde, etc), Kernel, programes d'ús comú (Firefox, Vlc, Chrome, Wine, etc.) tot el nivell de velocitat i optimització que tindries.
Aquest principi de compilació per obtenir un codi optimitzat especialment per la teva màquina és el que utilitzen distros com Gentoo i derivats (de què no vaig a parlar ara, jo faig servir Fedora minimal amb compilació del GNOME 3, el nucli i altres programes) on el sistema , les seves actualitzacions i els seus programes sempre sempre són compilats.
Desavantatges de la compilació:
Ja et vaig explicar tots els avantatges, però com tot en l'univers té una contra.
En el cas de la compilació són;
- Temps necessari per a això (Firefox amb un i7 4790K (sense overclock ja que sóc molt dolent amb els voltatges) pren 3 minuts, Gnome Shell (la barra res més) amb Gnome-Control-Center em prenc uns 2 minuts, els dos sent compilats alhora en Fedora. Però en una màquina amb un processador menys fort aquest temps pot augmentar desmesuradament).
- El processador utilitza el 100% de la seva potència amb tots els seus nuclis a l'màxim, de manera que el consum i la calor es disparen (tenir-ho en compte si té overclocking o si és especialment una notebook), així que és convenient que et preparis una esmaixada o un cafè per a l'ocasió.
- Potser et falti alguna llibreria (eina) que utilitzi algun programa perquè no d'error en la compilació. En general totes les distros tenen paquets o conjunts dels mateixos per evitar això (vénen plens de diverses llibreries i altres coses que permeten el nucli comunicar-se com es deu amb el processador durant el procés).
Com puc compilar?
Aquí parlo de compilar un programa d'ús normal, no un nucli.
aptitude install build-essential dh-make devscripts fakeroot debhelper debian-policy ccache dh-autoreconf autotools-dev build-dep ardour
Vaig posar debian-policy, però si la seva distro no és Debian i els dóna error que no existeix aquest paquet, simplement ignórenlo. He d'aclarir que fa molt que no ús aquests sistemes pel que si algun paquet ja no es troba en els repositoris no es facin problema.
Per Fedora:
sudo yum -i install kernel-headersdesenvolupament del nuclisuo yum groupinstall "Development Tools"suo yum groupinstall "Development Libraries"
Aquí he de demanar disculpes per als que fan servir Arch (no conec bé la distro) i OpenSuse, ja que no conec aquestes distros ni tampoc els paquets respectius per realitzar una correcta compilació (i no he corroborrado el que hi ha a la xarxa, per la que per aquestes dues no sé si funcionen).
Ara que ja tens tots els requeriments necessaris només necessites baixar-te el codi font de el programa que vols compilar, segons l'extensió ho descomprimeixes usant la terminal (tranqui, et deixaré les ordres) i quan tanques a la carpeta (sempre amb la terminal) fas el següent:
Si té possibilitat de configurar-se per triar els components i altres:
./configure
Després tecleges:
make
I finalment per instal·lar el programa al teu linux:
make install
Ordres per descomprimir mitjançant la terminal (l'arxiu es descomprimeix en una carpeta on es trobi l'arxiu):
Arxius .tar (tar) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Empaquetar | tar cvf arxiu.tar / arxiu / * Desempaquetar | tar xvf arxiu.tar Veure el contingut | tar TVF arxiu.tar
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .tar.gz - .tar.z - .tgz (tar amb gzip) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Empaquetar i comprimir | tar czvf arxiu.tar.gz / arxiu / Desempaquetar i descomprimir | tar xzvf arxiu.tar.gz Veure el contingut (sense extreure) | tar tzvf arxiu.tar.gz
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .gz (gzip) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Comprimir | gzip -q arxiu (L'arxiu el comprimeix i el renombra com "archivo.gz") Descomprimir | gzip -d archivo.gz (L'arxiu el descomprimeix i el deixa com a "arxiu" Nota: gzip només comprimeix arxius, no directoris
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .bz2 (bzip2) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Comprimir | bzip2 arxiu | bunzip2 arxiu (L'arxiu el comprimeix i el renombra com "archivo.bz2") Descomprimir | bzip2 -d archivo.bz2 | bunzip2 archivo.bz2 (L'arxiu el descomprimeix i el deixa com a "arxiu") Nota: bzip2 només comprimeix arxius, no directoris
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .tar.bz2 (tar amb bzip2) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Comprimir | tar -c arxius | bzip2> arxiu.tar.bz2 Descomprimir | bzip2 -dc arxiu.tar.bz2 | tar -XV | tar jvxf arxiu.tar.bz2 (versions recents de tar) Veure contingut | bzip2 -dc arxiu.tar.bz2 | tar -tv
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .zip (zip) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Comprimir | zip archivo.zip / maig / arxius Descomprimir | unzip archivo.zip Veure contingut | unzip -v archivo.zip
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .rar (rar) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Comprimir | rar -a archivo.rar / maig / arxius Descomprimir | rar -x archivo.rar Veure contingut | rar -v archivo.rar | rar -l archivo.rar
I això és tot. Salutacions des de Buenos Aires, Argentina. Bones festes i any nou! :).
El problema amb compilar és que no sempre funciona a la primera i és mes tediós
El problema de compilar és que a menys que tinguis un PC vellet i limitat, les millores no es notessin massa ... bé potser en un equip amb ús intensiu sigui una opció, però per a la majoria d'usuaris només és un procés tediós.
Crec que aquest és el moll de l'assumpte És tan important la millora de rendiment que es notarà a l'compilar els paquets, que farien que la pèrdua de temps i complicacions d'aquesta tasca passin a un segon pla?
Igual si tens a un i7 compilar sí que convé, perquè és més ràpid i calculo que funciona una mica millor. Ara amb un pc amb intel atom, no convé, llevat que necessitis realment aquesta potència extra que dóna compilar, però pot prendre hores compilar un programa amb un processador poc potent.
Coincideixo totalment, m'ha passat de compilar i assabentar-te després d'un temps que et cal una llibreria, rastrejar i haver d'encarar novament el procés ... És estrany que tot funcioni a el primer intent ... xD
Molt interessant!
Si compilas un programa, com funcionen després les actualitzacions? Són automàtiques o hem d'estar pendents nosaltres de si ha sortit una nova versió?
Ho has de actulizar el teu manualment és a dir compilar la versió més recent aquesta és una altra diguem-ne «desavantatge» per la qual també es fa una mica tediós
Doncs les actualitzacions no hi ha, de fet, les distribucions linux i les seves diferents formes d'empaquetar el programari i els corresponents gestors de paquets eliminen l'inconvenient de tornar a compilar per cada nova actualització (i de resoldre les dependències).
Salutacions.
Si el compilas descarregant el codi font des d'alguna pàgina, llavors sí has de fer-ho manualment i aprendre com instalaralo perquè no tots s'instal·len igual.
Ara, si tens Gentoo o alguna distro amb ports, llavors el fas des dels repositoris gairebé automàticament.
En Gentoo seu gestor de paquets, Portage, s'encarrega de les actualitzacions i les dependències; no sé en altres distros. Això sí, cada actualització suposa tornar a compilar, òbviament.
Hi va haver una època que compilava tot el que podia. Després em vaig cansar, sobretot pel temps que havia de dedicar al fet que la màquina treballés (45 min per al nucli, 10min per chromium ...) i pel temps que gastava en arreglar problemes que sorgien sobre la marxa. A més, jo personalment no vaig trobar un augment de rendiment, em donava la sensació que tot anava igual. Per aquestes raons ara ús tot precompilat, m'és tot instantani i sense conflictes. Encara que vaig aprendre molt en aquesta època, em vaig quedar amb les ganes d'usar gentoo 🙂
Fins i tot, i és una cosa que he vist poc, es pot compilar des de sistemes com apt. S'agrega una bandera de compilació a apt-source i llest. És clar, previ a això, instal·lar els paquets necessaris per a realitzar les compilacions, sinó no funciona ... tot i que és una forma més directa de compilació i que comporta menys passos, ja que, només la primera vegada ocupa la instal·lació de paquets i les següents, les dependències complertes i el paquet com a tal.
Salutacions.
Té la funcionalitat apt-build, encara que crec que no compila les dependències, sinó que instal·la binaris precompilats.
Des del primer instant que vaig veure el titular no vaig poder evitar pensar el mateix, i acabat de llegir tot l'excel·lent article tinc la idea al cap donant mil voltes, Gentoo ... Gentoo, ¿on aquestes ?,
compilar és una meravella, poder gaudir certes particularitats i usar-les és impagable, però el temps i les «necessitats actuals» és imperdonable, ja que no s'aplica.
Potser necessitem alguna cosa en mitjana, on ni llibreries ni detalls en canvi de versions ens faci perdre tant de temps. Veurem que passarà doncs, o si realment ens apliquem a compilar sobre el propi aptitude, uprmi i Zypper que ja tenim instal·lat.
3 minuts firefox! ... .habrias volgut dir 30?
Això demoro en el meu pc amb un fx8350 a 4.5G, ús gentoo.
$ Genlop -t firefox | tail -n3
Sat Dec 6 20:00:00 2014 >>> www-client / firefox-34.0.5-r1
merge time: 16 minutes and 35 seconds
Aquestes instruccions pròpies de cada processador es diuen mnemònics i estan implementades físicament dins de l'microprocessador, són les que conformen el llenguatge màquina, per tant compilar perquè un programa camini en molts tipus de microprocessadors, si o si han de fitar a el que menor quantitat de mnemònics comuns suportats en tots aquests icroprocesadores ... desaprofitant capacitat real dels microprocessadors més actuals i potents.
Així ho fan les empreses i les distros binàries gnu / linux.
Al meu amb un Intel i7 4790K amb 18gb de RAM m'ha pres el que vaig dir abans
Entenc que el micro que tens és superior, però la diferència és abismal, la veritat s'ha de veure un llençol a aquesta velocitat. Potser sigui alguna cosa relacionada amb les depencias o facis servir que són les mateixes que les opcions de l'configuri a l'compilar a mà.
petit detall q obviaste dir 18GB de Ram a part de l'i7, no tots tenen aquesta màquina, però podries fer un benchmarking així es nota una mica la diferència, perquè la teoria és bonica però a veure si compensa.
un altre gran detall, el processador és intel, per tant té independent de el model millor punt flotant, característica molt rellevant per realitzar aquest tipus de processos
És cert, compilar és tediós. Però s'aprèn molt renegant amb Makefiles, llibreries, etc. És una cosa que està bo fer encara que sigui un parell de vegades. Jo ús tot precompilat pel mateix motiu que va citar Tanrax.
Salutacions from Argentina!
El problema que generalment tinc a l'de compilar programes de versions totalment noves sempre és per les dependències, de vegades toca des compilar totes (per arribar a les ultimes versions) i després pensar en poder compilar el que es desitja.
Els problemes de PATH i els FLAGS són les coses que encara em mantenen a l'marge de voler compilar tot (encara que sòl fer-ho com puc). Una de les eines que sòl consultar per poder compilar les dependències és la següent web - http://www.linuxfromscratch.org/ -
#LinuxFromScratch és un projecte que proveeix instruccions «pas a pas» per compilar el codi font que necessitis utilitzar en el sistema .. (el 98% del que he necessitat compilar ho he aconseguit guiant-me d'aquí i poc a poc aprenent).
Com a punt a favor crec que compilar un sistema des de 0 seria interessant sobretot per a entorns de desenvolupament o servidors entre altres coses que diguem «no solen ser tan canviants» com un ordinador personal en la qual a cada estona estem instal·lant i canviant tot (és meu punt de vista) a més que el mínim de rendiment que es guanyi en aquest tipus d'aplicacions d'ús és molt important.
Són punts dels que molt poc es parla en l'actualitat i només els «erudits» manegen, però és interessant donar-li a aquest tipus de coses els tutorials que necessiten perquè cada dia trobem més gent que aporti ajuda a les diferents comunitats on participi i no només GNU / Linux quedi en el temps a causa de la poca acompliment dels col·laboradors, que si bé fins a l'actualitat «així ha funcionat» no és molt saludable comptar amb només Usuaris Finals.
Permet-me un petit afegit. Per poder obtenir els avantatges que aqui exposes, has de configurar adequadament el conegut make.conf. Alli s'indica la família de processador i les flags de compilació. De la mateixa manera, alli es pot especificar el nombre de nuclis a fer servir durant la compilació. Quan fas servir tots els nuclis de la teva micro, el temps de compilació es redueix de manera dràstica.
una salutació
Molt bo l'article. M'hagués agradat un exemple també o m'agradaria directament, un post sobre com compilar en ArchLinux o com utilitzar AUR. Feliç Any Nou des de Mendoza.
Fa molt de temps ... sempre compilava el nucli, però és molt tediós haver d'esperar 40 min: / en fi ... fa molt que no va compilar res a excepció dels drivers de vídeo (només per a unes configuracions especials).
Molt interessant l'article, però no senyor, empaquetar i compilar no és el mateix;) ..
Molt bon post. Estic d'acord en el de compilar certs programes, però de vegades és una mica tediós pel que demora la màquina en fer el procés. Però a part d'això un aprèn bastant, sobretot quan cal llibreries o paquets.
Crec que per Archlinux, per compilar es necessita el següent paquet: base-devel
pacman -S base-devel
Aquesta molt bona la info, però la veritat no cal compilar, si ets un user standar i només vols que alguna cosa funcioni com aquesta ni et toquis això. És tediós això d'estar compilant, sempre, dic sempre et falta alguna llibreria, et trobes amb un que un altre problema, digue-m'ho a mi que compili el server de minecraft perquè tot estigués el millor possible i em prenc el seu temps .... a part que cada vegada que surt un update o pegat o el que sigui posa't de nou a compilar xd
Exacte, compilar és per a programes molt específics que necessitis a un ús òptim, per que compilar tot, i com dius, sempre hi ha actualitzacions, major cas les distros rolling release, és molest. Recomanaria només els nuclis lts.
Avui dia gairebé tots els processadors que la gent fa servir suporten les mateixes instruccions, per tant compilar només és favorable quan es refereix a el nucli i en un sistema com ho pot ser un servidor, això, i obvi quan no hi ha paquets precompilats, tota la resta és perduda de temps.
Bona aportació, vaig a provar per veure que tal em va, fins ara la majoria de les vegades (gairebé sempre) instal dels repositoris ...
Petita observació: Les opcions de la comanda rar van sense guió i bunzip2 només descomprimeix.
el màxim que compili ser un nucli per debian wheezy i em trigo unes 2 hores (tinc un cpu amd E450 1.6 ghz dual-core) i justament per això no instal gentoo, el temps en compilar i baixar tot el sistema em portaria com 18 hores , i això si no tinc cap problema, és cert que és millor compilar però la majoria de vegades el temps trigat és massa i crec que no val la pena. tenes un plus de velocitat però no és molt i crec que no justifica tot el temps invertit. Encara que si algun dia arribo a tenir una pc amb un processador tan bo com el teu intetare instal·lar gentoo 😛
gent:
Sense intencions de flame ni res, els Slackers veuen com una cosa natural compilar, generar el binari, instal·lar-lo amb el gestor de paquets pertinent (que resolgui dependències òbviament, slapt-get, Swaret, slackyd i / o varis mes), amb tot optimitzat per nostre equip i com si res, que no és res de l'altre món ni física quàntica.
Veure un DVD sense que camini als batzegades en un P3 750MHz amb 192MB RAM no és una cosa ni impossible ni difícil d'aconseguir sobre un Slackware. Dono fe, i és més ràpid que compilar un Gentoo. Però no és el mateix, jo també ús Gentoo.
La diferència entre hacker i consumidor és que el consumidor diu "Desitjaria que funcionés de manera" i el hacker "Tinc un tornavís i uns pocs minuts" - Rael Dornfest
Realment hi ha una millora notable de l'rendiment?
Amb un i7 d'última generació i 18 Gb de ram, ¿com notes la diferència dels paquets compilats als binaris?
Sempre he odi sobre la idoneïtat de la compilació pròpia dels paquets, però crec que en els entorn d'escriptori actuals és molt complex de sostenir-ho, sobretot per la complexitat de les dependències, les contínues actualitzacions, i l'enorme dependència de fonts no lliures , com el cas dels drivers privatius, que influeixen sens dubte molta mes en el rendiment que qualsevol aspecte que es pugui compilar ...
Salutacions
Considerant que Gnome 3 només li compili (diré els noms bastament ja que els noms dels paquets no me'ls acord): el shell (la barra), el gnome-control-center (complet, amb les seves dependències, etc.), l'applet per el temps i unes 2 o 3 dependències perquè el shell pugui funcionar. Òbviament que el shell exigia més dependències perquè totes les seves funcions treballin però em portava a compilar GDM entre d'altres, això ho arregli modificant el amb GConf un cop compilat el shell.
Ara quan inici sessió (mitjançant terminal) l'entorn triga molt menys en carregar que quan tenia instal·lat de forma precompilada. Tirant un temps a l'aire, de manera precompilada crec que trigava uns 3 o 4 segons a carregar el shell (amb uns 5 en què es mostri el fons de pantalla, mai entesa per que trigava tant això, em sembla que és pel driver amb el GT 630) i compilat pel que fa ficava la contrasenya ja s'inicia X org i l'entorn està carregat (amb preload i prelink els vaig fer molt més ràpids, em sembla que és per que es van passar a la memòria cau; https://www.google.com.ar/search?q=preload+y+prelink+fedora&ie=utf-8&oe=utf-8&gws_rd=cr&ei=iXaqVPykO4qYNpbTgdAP )
El fet que el i7 tingui intruccions SS4 i SS3, les quals són ignorades per compilacions genèriques de diverses distros (debian compila per 486, ubuntu per 686) pot donar-te una idea de quan maquinari és malgastat tractant d'abastar un processador de 20 anys - igual gràcies debian per suportar el meu vell pentium mmx-. Si necessites «drivers privatius» com esmentes, el nucli brinda la possibilitat de carregar el microprogramari específic a l'hora de compilació. Mai més problemes estranys amb xorg.
Gràcies per la info, sempre és bo aprendre (o reaprendre) (:
Debian amb gustet a Gentoo 🙂
http://crysol.org/es/node/699
Un altre desavantatge és que la compilació per terminal és per a usuari que coneixen o tinguin ja una mica de coneixement sobre Linux. Hi ha alguna eina gràfica que no et administri la compilació, instal·lació i actualització de programes però de forma gràfica?
Calculate linux fa això, és un gentoo amb eines gràfiques llest per compilar. En Phoronix solen recomanar.
Sóc usuari de linux, algunes vegades quan vull instal·lar un programa des del repositori s'instal·len les versions antigues de el programa, simplement per que les noves no estan compilades per a la distro en qüestió, penso que saber compilar és fonamental, més encara quan es fan servir distros poc comuns.
Tot el que diu en el post està molt bé i no dubto que sigui cert, però la diferència de rendiment entre instal·lar un paquet binari i compilar tu mateix és imperceptible per a un usuari.
I els desavantatges de compilar són moltes i si són clarament perceptibles per a l'usuari. Per tant personalment pas de compilar.
On més he notat el rendiment a l'compilar el nucli, va ser en un portàtil amb processador AMD 64. El canvi entre el nucli de fabrica i el compilat era brutal.
Ara mateix, tinc nucli de fàbrica en el meu sistema, ja que com diuen molt per aquí, hi va haver una època en la que compilava gairebé tot i em arribi a cansar.
Ara mateix, només va compilar alguns programes de vital importància, com per fer ús d'un petit servidor, o per jugar amb emuladors. No fa gaire vaig fer un post de com compilar la versió de mami. Aquests programes generalment si es nota quan el tens optimitzat per al teu sistema.
Només em falta provar aquesta distro de gentoo, i veure com camina el rendiment.
Es m'oblido afegir, a les persones que li dura molt compilant el nucli, més de 30 minuts, hi ha diversos trucs per fer-ho en menys temps.
Un d'aquests trucs, és que, només compile els mòduls de la teva equips, màxim, potser 70 mòduls com a molt és el que li apareguin a vostès i si afegim el suport d'iptables amb tots els seus requisits, crec que augmentaria a 300 mòduls. Anem, que és molt millor que compilar 3000 i escaig de mòduls, xifra que camina actualment si es compilen els mòduls de l'nucli com ve de fabrica o com li diuen, vanilla.
El programa que els ajudés a saber quins mòduls reconeix el nucli al teu sistema actualment, és «localmodconfig» o fent ús d'aquest script «streamline_config.pl» que es troba dins de directori de l'nucli source, en la ruta «/ scripts / KConfig / »
Això si, assegurin-se de tenir tots els seus aparells usb connectats, ja que una vegada que el nucli reconegui tots els seus mòduls, només és qüestió de compilar.
El nucli estarà ben lleuger i se sentirà cert aire de frescor en el sistema, així com també s'afanya més l'inici i apagat de el sistema.
Salutacions.
La vida no és tan fàcil! hi ha programes que fan servir cmake o altres coses, a més mantenir tot actualitzat i compilat porta temps. I tenint semblant CPU que diferencia et va a fer?
El problema amb compilar és que alguns dels programes que instal·lem amb aquest mètode després no es desinstal·len o donen errors a fer-ho amb la qual cosa no podem desinstal·lar-los.
Has de guardar la carpeta amb els fonts compilats, quan et deen ganes de desinstar, l'únic que has de fer és anar a la carpeta dels fonts i des d'una terminal com a root executar:
# Make uninstall
Per descomptat, els paquets compilats a mà per defecte en tota distro seriosa s'instal·len a part, o sigui en / usr / local / bin no en / usr / bin on els posa per defecte el gestor de paquets de la distro, així d'aquesta manera no s'empelta res.
L'article planteja diverses coses interessants però no té una qualitat pèssima en els seus termes i estructura lògica ..
«En un programa executable per al seu funcionament mitjançant l'ús de l'PROCESSADOR per a la conversió de l'llenguatge usat per generar el codi a l'binari i assemblador. També se li sol cridar empaquetament. »
Fals. s'usa realment un Compilador és l'encarregat de passar les instruccions d'un determinat llenguatge de programació al seu corresponent en llenguatge assemblador i després traduir aquest a llenguatge màquina.
El llenguatge assemblador és un mnemotècnic que reflecteix un grup d'instruccions residents en els registres de l'xip.
«A l'baixar, descomprimir i compilar pel teu compte el codi font d'un programa, aquest es compila amb les instruccions específiques de TU processador»
A l'compilar un programa simplement es farà amb les intruccions comuns a l'arquitectura depèn de cada usuari activar les flags corresponents de compilador per aconseguir optimitzar un programa per a un processador de forma específica.
Referent al que comentes sobre compilar el nucli:
Quan compilas el nucli busques activar o desactivar característiques que poden ser útils o no en un determinat moment la qual cosa no necessàriament es veurà reflectit en la relació mida i velocitat en la càrrega de execusió.
Quan et refereixes a l'apartat:
dh-make devscripts fakeroot debhelper debian-policy ccache dh-autoreconf autotools-dev build-dep
Aquests programes no són essencials per a compilar un programa. Tal com intentaves dir a l'inici, la quantitat de llenguatges de programació impedeix saber del cert que eines has de tenir instal.lades per poder compilar programes en gnu / linux ... això ho pots saber només consultant la documentació de el programa que quiras realitzar. Els programes que esmentes es fan servir per a procedir a debianitzar i empaquetar en aquest format un programa que podria estar o no compilat.
Hi ha altres assumptes en article que resulten ser un tant ambigües en la forma en què es plantegen. Seria ardu abordar-les totes.
Suggereixo la revisió de l'article en la mesura del possible per part del seu creador i s'insta a un millor control en la qualitat de les publicacions.
Home, tampoc és això.
L'article no és per a la revista Science, simplement és un article introductori, i crec que en els termes en els quals els fa, són prou profunds perquè un usuari novell comprengui els conceptes clau.
Si ens posem acadèmics, tres quartes parts del que es publica a internet no valdria absolutament de res.
No siguem tan puristes ... és impossible estar a el 100% d'acord amb un article, però tampoc podem anar valorant la qualitat «tècnica» contínuament, com si anéssim a avaluar un doctorat.
El meu suport total a l'autor d'aquest article
interessant article
sempre és bo per als amants de la llibertat, l'ús de UNAR, en comptes de rar, per descomprimir rars de forma lliure. ( https://packages.debian.org/jessie/unar )
Em bec la bestiola amb aquest tema ... em vaig posar a buscar a google però no trobo un tutorial per compilar firefox sota ubunto 14.04 amd64 bits ... po demas, aquesta nit em poso amb el nucli amb el sig tutuo: http://www.redeszone.net/2014/11/28/como-instalar-el-ultimo-kernel-de-linux-en-ubuntu-14-04-lts/
bon article, estic aprenent molt. però faria servir això només per algun programa específic que consumeixi molts recursos, com editors de vídeo per exemple. salutacions.
Entre aquest article i el de Gentoo que van publicar fa uns dies em tempten a instal·lar Gentoo en el meu PC. Fa molts anys vaig fer servir Sabayon, que facilitava tot el procés d'instal·lació però mantenia la base que és compilar des font. Sincerament no recordo haver notat alguna diferència en l'exercici de la meva Laptop (en aquest temps tenia una lap) amb Sabayon o amb Ubuntu, per la qual cosa no sé si aventarme tota la feina d'esborrar la meva Arch que funciona molt bé per a instal·lar-lo. No estic segur que uns mil·lisegons per programa valguin la pena.
De les 4 pcs amb gentoo que tinc instal·lades i actualitzades, se suma la notebook que tenia ArchLinux ... .me cansar systemd, ja havia de fer-la servir amb startx perquè en l'última actualització es va disparar a el 85% d'ús dels dos nuclis, sense fer res, vaig estar investigant i sembla que alguna cosa ha canviat en systemd perquè slim es embogeixi i em mengi el microprocessador.
Ja n'hi ha prou, va ser suficient amb fitxers ... .demaciado va aguantar, més de dos anys, ara estic instal·lant gentoo, vaig per l'actualizacion a testing de l'stage3, per aquesta nit marxarà XNUMX OPENBOX amb fregides.
Bon article, em donen ganes de compilar Qupzilla, però amb un Sempron trigarà dies, bé, es que no tant, però tot i així dóna fiaca.
Un altre desavantatge que té la compilació és que quan hi ha una actualització cal tornar a compilar i instal·lar l'actualització, la qual cosa és un problema si es té en compte que alguns programes tenen cicles de desenvolupament curts i per a ells s'emeten actualitzacions amb freqüència, 2 a 3 mesos, amb tot això l'usuari casual s'avorreix i l'usuari constant consumeix molt temps en mantenir el seu sistema a el dia.
m'agradaria saber quins aplicacions és més recomanat compilar. segons la seva utilitat, freqüència d'actualització i millora en rendiment.
Això és absurd, si requereixes compilar tu mateix, és que estàs fent servir la distribució incorrecta. L'única raó per compilar és per afegir opcions de debug i que et vagi més lent a tu, a canvi de poder arreglar millor els errors d'altres.
El vostre sistema no va lent perquè necessiti -O3, va lent perquè hi ha algun programa llegint massa a disc o pintant massa en pantalla.
La meva recomanació: en comptes de microoptimizar nostre sistema, treballem en comunitat per millorar el programari de què disposem entre tots.
No has explicat com opitimizar la compilació, per exemple en Gentoo s'usa les opcions de USE per poder optimitzar el codi generat, a més has d'indicar el processador, etc. Com es fa això en UBUNTU / Debian o en Arch ?, Interessant Article.
Bones!
A falta de llegir els comentaris de sota tinc una dubteu i novell en linux:
Ús Fedora 20, ja tinc bastants cosetes instal·lades, per exemple, el navegador Firefox, per compilar-lo per la meva màquina, ho puc fer sense més ?, és a dir, sota el codi i el va compilar, o he primer que eliminar el programa que ja tinc baixat per compilar el nou ...
El mateix amb el nucli de Linux i tal ....
Potser estigui preguntant una cosa absurda però ja dic que sóc bastant novell en les coses serioses de Linux jajaja
Una salutació!
El nucli crec que no cal, però has de crear una entrada per a cada nucli en el GRUB, amb firefox no si és recomanable tenir 2 firefox, personalment prefereixo tenir 1 només nucli i 1 només firefox
L'únic que he compilat en la meva vida ha estat una versió en desenvolupament de Musique, m'agrada molt aquesta app, va valer la pena tot el temps que trigui el procés. Per a un usuari final com jo, a l'acabar, em vaig sentir realitzat.
Salutacions, excel·lent bloc.
Hola jo faig servir Slackware i compilar les aplicacions és el més normal de món.
El sistema t'ho instal·les des d'una ISO ja precompilat, i les aplicacions precompiladas que pots utilitzar des del repositori oficial són poques, encara que si tu vols pots descarregar el codi font de sistema (i els scripts originals amb els quals es compila tota la distro) i compilartelo tu mateix que és com jo imagino que funciona Gentoo.
No obstant això el projecte SlackBuilds proporciona scripts (semblants als oficials de la distro) per a moltes aplicacions de tercers, en els quals et descarregues el codi font del que vols instal·lar i el converteixes a un paquet tgz o txz que posteriorment s'instal·la amb el administrador de paquets oficial de la distro. Per tant, l'avantatge és que t'evites utilitzar les comandes configuri, make, make install i pots actualitzar, reinstal·lar o remoure el paquet com qualsevol altre i de manera molt fàcil.
El desavantatge és que en Slackware les dependències no es resolen automàgicament com en altres distros, així que has de compilar les dependències necessàries primer i a la fi l'aplicació que vols instal·lar. Els programes que jo faig servir compilats són des LibreOffice, Texmaker, Spyder, Qt5, QtCreator, VLC, Wine, GRASS, QGis, entre d'altres. Depenent de l'aplicació i els seus requeriments, la compilació i instal·lació pot trigar entre 5 minuts o diverses hores. Però si ho desitja pots buscar i fer servir un paquet precompilat per estalviar-te temps.
No he tingut temps de comprovar si hi ha molta diferència entre els paquets compilats i els precompilats, però el meu sistema és molt estable. Però jo crec que a el menys en el meu portàtil no hi ha molta diferència ja que no és tan potent, té un processador i3 i 4 GB de RAM.
Salutacions i sort compilant.
Actualment estic fent servir Funtoo, per ser honest no veig cap diferència de rendiment entre compilar un programa o instal·lar el precompilat, jo ho faig merament per un tema pedagògic, però si hi ha diferències entre compilar el nucli i no fer-ho, això si. Quan feia servir debian i desitjava compilar alguna cosa, feia servir la següent seqüència:
. / Configure
Make -j3 (nombre de cores + 1)
Estranger
Feia servir s'aliïn perquè crea un binari de el programa compilat i així pots instal al teu sistema com un binari qualsevol, i així, si voleu desinstal·lar, simplement pots fer servir el synaptic o una altra gestor de paquets, aquesta és l'avantatge de crear el paquet i instal·lar el paquet com a tal, en lloc de fer «make install»
Jo si que li veig una millora, al menys amb paquets grans i pesats, per exemple LibreOffice een Funtoo triga molt menys en carregar que a Debian, el mateix m'ha passat amb VLC o amb MPV i arxius MKV FullHD i multiaudio, la càrrega és molt més ràpida.
Un altre que també ha patit el canvi és Firefox, en Debian tenir 10 o 15 pestanyes amb el meu PC es torna una tortura, però amb Funtoo he aconseguit tenir fins a 30 obertes i segueix com si res i el consum de ram és molt més baix i menys tendent a freeze pels arxius JS, jo crec que depèn més aviat el context en com s'executen certes tasques i programes.
El problema és que quan ho descarreguem precompilats estem convertint qualsevol distro de linux en una basta còpia de windows
Jo més que en un augment espectacular en el rendiment li veig l'avantatge en la possibilitat de compilar els paquets amb els components que un vol: per exemple, si no tens impressora pots indicar que no es compilen els paquets amb suport per a CUPS -els paquets que usin CUPS, òbviament, si compilas Hunspell amb o sense CUPS donarà igualment tan sols -almenys en Gentoo- indicant en el fitxer make.conf, on se centralitzen totes les opcions de la construcció de paquets «-cups»; si fas servir KDE5, o Plasma 5, com li diuen ara, pots indicar les etiquetes «-kde», «-qt4», que eren etiquetes vàlides per a KDE 4 però innecessàries en KDE 5 i aplicacions portades a el nou escriptori, «-gnome» , «-gtk», i així amb qualsevol component que sàpigues que no necessites. Si per algun motiu un programa concret necessita, diguem GTK, doncs després pots, en un fitxer que es diu package.use, indicar que sí usi GTK, per exemple per Pidgin amb la mateixa etiqueta però sense el signe menys, és a dir «gtk »:« net-im / pidgin gtk ».
D'aquesta manera s'aconsegueix un sistema diversos centenars de megues més lleuger i binaris més petits i eficients, al no tenir codi innecessari. Jo he anat des d'Ubuntu a Gentoo passant per Opensuse, Kubuntu, Debian, Arch, Chakra o Kaos, i Gentoo és el sistema més ràpid que he tingut, i segueixo tenint el mateix Core 2 Duo que tenia fa 7 anys. Això sí, les compilacions les deixo per a la nit, perquè compilar QT5 ara suposa diverses hores. Si s'ajusta el paràmetre «niceness» per Portage a make.conf es poden instal·lar paquets o actualitzar mentre se segueix treballant amb la màquina i amb prou feines es nota molta alentiment, encara que òbviament el temps de compilació augmenta; però anem, amb posar-lo a instal·lar o actualitzar quan em vaig a sopar, i si cal deixant-treballant durant la nit, el meu vell ordinador funciona millor que el I3 de la meva núvia amb Kubuntu.
Un altre aspecte cada vegada més important és que a l'compilar des d'arxius font la seguretat que el paquet que estem instal·lant és l'original, que no ha estat manipulat per tercers, és gairebé total. Crec que Debian està implementant un sistema de verificació de les compilacions que garantirà una mica més que el precompilat que instal·lem realment prové de la font original, però mai hi haurà tanta certesa quan aquest paquet ha estat compilat en la nostra màquina amb la nostra configuració.
Al meu entendre, amb un processador modern, no una carraca com el meu, jeje, i, si volem accelerar el procés, amb 8 GB de RAM per poder muntar / var / tmp -la carpeta temporal que fa servir Portage per a la compilación- en RAM, que sempre serà més ràpida que un disc dur o un SSD, ara per ara no li veig molt sentit a usar paquets precompilats. Si en el meu equip Firefox tarda a compilar uns 40 minuts, quant pot trigar en un I5 o I7 dels que estan actualment al mercat, 5 minuts, menys fins i tot ?. Parlo de l'firefox font, no de l'firefox-bin, que és un paquet binari ja precompilat que es pot instal·lar en Gentoo si es té una màquina molt lenta -hi ha diversos paquets grans que ja s'ofereixen precompilats per aquest motiu, no és obligatori compilar tot -. No puc parlar perquè la meva xicota no em deixa trastejar al seu ordinador, jeje, i el meu va tan bé que no sento la necessitat de renovar-lo, però si estic en el cert, crec que val la pena perdre uns minuts compilant per poder tenir un sistema fet a la nostra mida. Més ajustat i adequat a la nostra màquina no crec que es pugui aconseguir res sense entrar ja en els mètodes aquests de Linux des de zero, Linux from scratch, que crec que ja queda reservat per a informàtics o coneixedors molt avançats de Linux.
Salutacions.
Molt bo!
una sola cosa no existeix el «Amd Atom x2»
ni existirà és una marca comercial d'intel
salutacions