![[FSF Associate Member]](skins/waiting/images/fsf.png){kind=small}
25/10: Problemes en l'actualització a Ubuntu 7.10 Gutsy Gibbon (2a part)
* Passar el sistema a AIGLX
* L'acceleració 3D es perd després de reiniciar el sistema
* Volum baix en la targeta de so
1) Passar el sistema a AIGLX
Després d'un parell d'arrancades me n'he adonat que el suport 3D desapareixia cada vegada que reiniciava la màquina! Però com que van sortir els drivers nous he aprofitat per arreglar-ho tot de cop.
La instal·lació dels nous drivers va de la mateixa forma que abans però ara abans podem fer neteja:
$ sudo apt-get remove xserver-xgl
$ sudo apt-get remove xorg-driver-fglrx
$ sudo rm -f /usr/src/fglrx-kernel*.deb
Després d'això podem anar per descarregar i instal·lar els nous drivers amb el mateix procediment d'abans i sobretot assegurar-nos de que no farà servir els de la distribució posant a /etc/default/linux-restricted-modules-common
DISABLED_MODULES="fglrx"
Un cop instal·lats hem d'editar el /etc/X11/xorg.conf per treure-li el que no permetia el suport AIGLX. O sigui esborrar les seccions que facin referència a "composite" o "AIGLX". En el meu cas eren aquestes:
Section "Extensions"
Option "Composite" "0"
Option "Composite" "Disable"
EndSection
Section "ServerFlags"
Option "AIGLX" "off"
EndSection
I després de reiniciar el servidor podem arrancar compiz!. Ubuntu fa comprovacions abans d'arrancar i no deixa que arranqui Compiz amb fglrx. O sigui que queden dues opcions:
1) Dir-li que no faci les comprovacions
$ SKIP_CHECKS=yes compiz
2) Modificant l'script d'inici perquè permeti fglrx
Editant el /usr/bin/compiz i afegint fglrx a la línia que defineix les targetes acceptades (WHITELIST):
...
WHITELIST="nvidia fglrx intel ati radeon i810"
...
Aquesta segona opció ens permetrà executar directament compiz
$ compiz
El resultat és que Compiz em funciona bé en GNOME i pensava que no em funcionava en KDE però el que passa és que sembla que la configuració és independent entre els escriptoris
Categoria: Linux | Fet per: Xavier | |
21/10: Problemes en l'actualització a Ubuntu 7.10 Gutsy Gibbon
L'actualització ha durat al voltant de tres hores i al reiniciar el sistema m'he trobat amb uns quants problemes:
1) Caiguda del rendiment del sistema. Per algun motiu el sistema va molt lent, es veu com va repintant les pantalles quan es fa scroll...
2) Les icones de l'escriptori en KDE han quedat totalment corrompudes:
Curiosament en Gnome només ha quedat corrompuda la icona de Tomboy de la barra d'eines
3) El teclat no funciona correctament, no es poden escriure els símbols de sobre els números!. Per exemple no es pot escriure '|'.
4) Els combobox del sistema tenen un comportament erràtic, com si fessim múltiples clics al damunt durant una estona...I fins que no deixa de pampalluguejar no es poden desplegar.
5) He deixat de tenir acceleració 3D
6) No em funciona el so
Primera solució
Com que sembla que no repinta gaire bé la caiguda del rendiment una part podria ser deguda a falta d'acceleració de la targeta gràfica. No sé perquè però molts dels problemes que tinc són deguts als per ara deficients drivers d'ATI en Linux.
Per tant com que tinc una Mobility Radeon he instal·lat a mà els drivers oficials 8.40.4 (ja que els 8.41 tenen problemes amb aquestes targetes).
Això ha fet que hi hagi una millora en el rendiment del sistema molt important però encara queden els problemes de les icones corruptes, del teclat, el funcionament dels combos i encara no tinc acceleració 3D
Enllaç: Instal·lar drivers ATI en Ubuntu
Categoria: Linux | Fet per: Xavier | |
23/09: Adéu democràcia
Tot va començar el 2002 quan els parlamentaris espanyols van demostrat que la "llibertat d'expressió" és només una paraula per ells i que no els importa gens. I per deixar-ho clar van aprovar la LSSI (Lei de Servicios de la Sociedad de la Información) que ara està deixant clar perquè es va fer...
A la pàgina web "alasbarricadas.org" es van fer comentaris que el senyor "Ramoncín" va considerar ofensiu. Com que els comentaris no els havia fet cap membre de la web sinó visitants i com que la senyora jutge volia condemnar a algú, ha condemnat al que va comprar el domini perquè les seves dades no estaven exposades en la seva pàgina web perquè les pugui veure tot el món! (segons la LSSICE artícle 10).
Sembla que això no serà un cas aïllat: la SGAE té més demandes a punt (Merodeando, la revista Quimera,...). Almenys ara ja se sap perquè els de la SGAE necessiten tants diners. Amb els diners que recaptaran pel cànon sobre dispositius digitals la SGAE es dedicarà a demandar a qui faci comentaris que no els agradin.
Un cànon que és molt interessant perquè demostra que el govern espanyol considera a tothom culpable de pirateria (presumpció d'innocència? Ja ja ja).
O sigui, que fins que la SGAE pugui censurar les pàgines d'ofici, cosa que el PSOE sembla que els vol permetre, els que tinguin pàgina web estan obligats a posar públicament les seves dades i a CENSURAR els comentaris que faci la gent perquè poden ser considerats responsabilitat del webmaster encara que no hi hagi cap sentència judicial!. Perquè també és important saber que no s'ha tingut en compte que els comentaris van ser esborrats quan es va rebre la demanda.
Si sumem tot això a el que va passar amb la caricatura del Jueves, etc... no ens queda més remei que ser ben educats i dir: Adéu llibertat d'expressió (base de la democràcia), va estar bé mentre pensàvem que en teníem.
Fonts:
Bloguespierre
Kriptòpolis
La sentència
Internautas.org
Categoria: Programari Lliure | Fet per: Xavier | |
12/09: Canviar adreces de xarxa en Linux
Com que vaig posar com canviar adreces IP de Windows des de la consola crec que també està bé que ho faci en Linux. Tot això també es pot fer a partir dels diferents entorns gràfics que té cada distribució però és molt més interessant poder-ho fer a través de la consolaCanviar adreça IP
Per posar una adreça de xarxa a una targeta ho fem amb:
# ifconfig eth0 192.168.0.69 netmask 255.255.255.0
# route add default gw 192.168.0.2
En aquest cas especifiquem que l'adreça IP de la targeta eth0 serà 192.168.0.69 i que el gateway serà 192.168.0.2
Per rebre l'adreça a través de dhcp, només hem d'especificar-ho amb:
# dhclient eth0
A diferència del que passa en Windows, en Linux el canvi no és permanent. Encara que és molt útil per poder canviar les adreces de forma ràpida en un moment donat, si volem que el canvi sigui permanent cal que canviem els fitxers d'inici de la xarxa. Això es fa de formes diferents en funció de la distribució que tinguem
* Configuració de xarxa permanent en Ubuntu/Debian
La configuració de la xarxa en Ubuntu/Debian està en l'arxiu /etc/network/interfaces. Per tant només hem d'editar-lo per aconseguir que s'adapti al que volem.
Per posar una adreça fixa, canviem totes les referències a la targeta per:
iface eth0 inet static
address 192.168.0.69
netmask 255.255.255.0
gateway 192.168.0.2
Si volem que la targeta rebi l'adreça per dhcp canviem totes les refències a la targeta que volem canviar i les substituim per (eth0 en l'exemple):
auto eth0
iface eth0 inet dhcp
* Configuració de xarxa permanent en Red Hat/Mandriva/Fedora
En els sistemes basats en Red Hat l'arxiu a editar és /etc/sysconfig/network-scripts/ifcfg-eth0 (la part final del nom especifica la targeta a la que farem referència.
Per posar l'adreça fixa de l'exemple anterior editem l''arxiu i al acabar hem de tenir una cosa semblant a això:
DEVICE=eth0
IPADDR=192.168.0.69
NETMASK=255.255.255.0
GATEWAY=192.168.0.2
ONBOOT=yes
Si el que volem és que les adreces s'aconsegueixin a través de dhcp el contingut de l'arxiu ha de ser com:
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
Canviar els servidors DNS
Els DNS es canvien igual en qualsevol de les distribucions. Cal tenir en compte que en Linux no hi ha diferents DNS per cada una de les diferents targetes de xarxa, només hi ha un sol fitxer que conté l'adreça del DNS que farà el nostre sistema.
Aquest arxiu és /etc/resolv.conf, l'editem i hi posem l'adreça del DNS en el lloc de la que hi hagi. Si volem posar 80.58.0.33 com a servidor DNS editem l'arxiu i hi posem això:
nameserver 80.58.32.97
Categoria: Linux | Fet per: admin | | 2 Comentaris
11/09: Canviar adreces de xarxa en Windows amb netsh
Com que no actualitzo gaire sovint intentaré posar coses que fa temps que ja sé fer però que trobo que està bé que siguin més conegudes.Una de les comandes de consola sota Windows que és més interessant és netsh. Es tracta d'una eina per visualitzar i/o modificar, de forma local o remota, la configuració de xarxa d'un ordinador en Windows. També dóna capacitats de funcionament a través de seqüències per permetre executar una sèrie de comandes en batch.
Una de les coses que em posava més dels nervis de Windows era el pesat procés de canviar d'IP a través dels assistents gràfics: "Entorno de Red", "Propiedades" etc.. .
Però gràcies a netsh podem fer en canvi d'adreces IP des de la consola!
La primera cosa que ens cal és saber quin es el nom que Windows dóna a la targeta de xarxa que tenim en el sistema. Normalment sempre és el mateix en les versions d'idioma. En les versions en castellà sempre es sol dir "Conexión de área local", però podem averiguar-ho amb la comanda següent:
C:\> netsh interface show interface
Estado admin. Estado Tipo Nombre interfaz
----------------------------------------------------------------------
Habilitado Dedicado Conexión de área local
Habilitado Bucle invertido Bucle invertido
Habilitado Interno Interno
Canviar l'adreça IP
Un cop sabem com es diu podem posar IP fixa a qualsevol ordinador amb la comanda: (és una mica llarga però ... )
C:\>netsh interface ip set address "Conexión de área local" static 192.168.0.69 255.255.255.0 192.168.0.2 1
Aceptar
En aquest exemple poso l'adreça 192.168.0.69 a la targeta, i li dic que el gateway és 192.168.0.2
Si volem que la targeta obtingui l'adreça a través de dhcp la comanda és una mica més curta:
C:\>netsh interface ip set address "Conexión de área local" dhcp
Aceptar
Les comandes són una mica llargues però és un procés menys engorrós que fer-ho a través de l'entorn gràfic!
Canviar els DNS
També podem canviar els DNS associats a cada una de les targetes de xarxa de forma similar. Per posar 80.58.0.33 com a DNS fixe a la targeta fem servir:
C:\>netsh interface ip set dns "Conexión de área local" static 80.58.0.33
Aceptar
També podem dir-li que accepti els DNS a través de DHCP amb la comanda següent:
C:\>netsh interface ip set dns "Conexión de área local" dhcp
Aceptar
Un sistema molt més útil que fer-ho a través de l'entorn gràfic i amb l'avantatge afegit que també es pot fer en altres màquines remotament afegint el paràmetre -r.
Categoria: Windows | Fet per: Xavier | |
10/09: FreeNX a Ubuntu
Normalment per administrar remotament el server en tinc prou amb la consola però algun cop, normalment per treballar amb alguns programes gràfics amb els que no se'n pot veure l'estat des de consola, necessito alguna forma d'accedir gràficament de forma remota a algun programa. Fins ara quan em trobava en aquest cas feia servir alguna de les variants de VNC. Però per mi VNC té un parell de problemes:- La seguretat: El xifrat de els contrasenyes de VNC és poc segur. I crear túnels SSH cada vegada és un rotllo
- La velocitat: El seu funcionament no és gaire ràpid. Especialment amb connexions lentes.
Com que havia sentit a parlar molt bé de NX i com que una de les coses que en destaquen és la seva gran velocitat m'he decidit a provar-lo.
Segons la seva web:
NX és un sistema que permet l'accés a l'escriptori a través de TCP/IP. Dóna una velocitat semblant a la que hi ha en connexions locals fins i tot a través de línies amb respostes de latència alta, o en enllaços de banda baixa. El nucli de les llibreries pertany a la empresa NoMachine i està sota llicència GPL. FreeNX és una implementació GPL del servidor NX.
Instal·lació del servidor a Ubuntu Feisty
A la màquina que s'ha d'administrar remotament li hem d'instal·lar el servidor freeNX. En Ubuntu això té el problema que en els repositoris per defecte no hi ha freeNX.
Això només implica que no podem instal·lar-lo només amb "apt-get install" sinó que:
- O el recuperem des de codi font i el compilem nosaltres
- O bé es busca algun repositori que ja el tingui empaquetat perquè el puguem fer servir
Una simple recerca a Google ens dóna que hi ha un repositori anomenat Seveas on hi ha els paquets preparats per diferents versions d'Ubuntu. Per trencar amb el que faig sempre, faré servir el paquet d'aquest repositori.
Per afegir "Seveas" als repositoris gestionats automàticament de la meva màquina editem l'arxiu /etc/apt/sources.list i hi afegim les dues línies següents:
deb http://free.linux.hp.com/~brett/seveas/freenx feisty-seveas freenx
deb-src http://free.linux.hp.com/~brett/seveas/freenx feisty-seveas freenx
Com que es tracta d'un nou repositori que gestionarà automàticament hem de descarregar les seves claus públiques per poder comprovar que els paquets no han estat modificats quan els descarreguem
$ wget http://free.linux.hp.com/~brett/seveas/freenx/seveas.gpg -O- | sudo apt-key add -
Després d'actualitzar ja podem fer la instal·lació del servidor:
$ sudo apt-get update
$ sudo aptitude install freenx
Categoria: Linux | Fet per: Xavier | |
16/07: Fer ping a bitacoles.net amb Nucleus CMS
Els dos blocs que estic fent servir actualment estan en Nucleus CMS
Perquè tinc els meus blocs amb Nucleus?
Per diversos motius: perquè està en GPL, i perquè moltíssima gent fa servir Wordpress i per tant jo en faig servir un altre.
1) Fer ping a bitàcoles.net
El problema estava en que jo volia que quan jo faci una entrada en el meu bloc de còmics aparegués en la llista de bitacoles.net (o sigui fer-li un ping quan es crei una entrada) i això no es pot fer per defecte amb Nucleus 3.24. I en la web que he trobat que deia que havia modificat el connector per fer-ho l'enllaç de descàrrega no funciona.
Nucleus CMS 3.24 només fa pings a weblogs.com però disposa d'un connector (plugin) NP_PingPong que li permet fer pings automàticament a diferents llocs: ping-o-matic, blo.gs, Weblogues, Blogg.de, Technorati, Blogrolling. Això està molt bé, però malauradament per nosaltres bitàcoles.net no hi és.
Està clar que una altra solució hagués estat crear un compte a ping-o-matic i que aquest fos el que s'encarregui de fer ping a bitàcoles, però no és una solució que m'agradi gaire o sigui que vaig decidir anar més enllà.
El primer és saber quin sistema fa servir bitàcoles.net per acceptar els pings. A la seva web hi trobem:
Bitacoles.net implementa el sistema de notificacions d’actualitzacions de bitàcoles de www.weblogs.com. Cada cop que s’actualitza la bitàcola mitjançant una crida XML-RPC es pot notificar el canvi a bitacoles.net.
...
Si utilitzeu alguna eina per publicar la vostra bitàcola, només caldrà que cerqueu si té l’opció de fer un ping. I si la té poseu la següent url de un ping: www.bitacoles.net/notificacio.php.
O sigui que hem de fer que faci com si es tractés d'un ping a weblogs.com amb XML-RPC a l'adreça http://www.bitacoles.net/notificacio.php
Categoria: Programari Lliure | Fet per: Xavier | |
03/07: Què fer quan es mor la barra de KDE?
Això és una cosa que no em passa gaire sovint però de tant en tant em passa amb la meva instal·lació de Kubuntu feisty i també em passava en les versions anteriors de Kubuntu. Per això deixo anotada la solució aquí per si li passa a algú més.El problema està en que a vegades, m'ha passat quatre o cinc cops des d'abril, per algun motiu que desconec la barra de menus desapareix i no hi ha forma de fer-la tornar a aparèixer.
Ja que hi sóc, explicaré tots els intents que vaig fer per intentar trobar la forma de fer-la aparèixer de nou i per veure si trobava perquè passa:
1. Reiniciar el programa que ha petat
Podia haver estat que el problema estigués en que el programa que s'encarrega del menú, kicker, estigués penjat i per tant es podia provar de reiniciar-lo.
Afortunadament el fons d'escriptori continua funcionant i podem crear una consola amb "Executa una comanda" i executant "konsole" (el podria engegar directament però l'engego des de la consola per poder veure si dóna missatges d'error).
El kicker només deixa que se l'executi una sola vegada, per tant si ja està en marxa l'hem de matar.
$ killall kicker
$ kicker
Això no va tenir cap efecte. La nova execució del kicker continuava sense mostrar la barra i entre els missatges que dóna no hi ha cap pista per trobar el problema...
2. Reiniciar la sessió
Després vaig provar un dels clàssics, LA gran influència de Windows en la informàtica actual: reiniciar la sessió per veure si es tractava d'un problema puntual (algun programa s'ha penjat i..). En Windows el que faria seria reiniciar la màquina, però això no és Windows :-)
Per reiniciar la sessió n'hi ha prou amb fer la combinació de tecles CTRL+ALT+BACKSPACE
Això no solucionava el problema, cosa que em va fer creure que probablement el problema estava en algun fitxer (dades persistents).
3. Pot ser un fitxer que estigui bloquejat?
De fet no pot ser que estigui bloquejat perquè si aquest fos el problema, la reinicialització del sistema faria que tornés a sortir la barra perquè el fitxer deixaria d'estar bloquejat.
El que si que podria ser és que algun fitxer de configuració hagués quedat corromput d'alguna forma. Vaig estar una estona inspeccionant l'estat del procés amb lsof sense trobar cap resultat i no he vist res estrany en els fitxers. Aquesta és la solució que hauré d'explorar amb més detall quan em torni a passar perquè em pot indicar realment què està passant.
4. Primera solució ràpida: Liquidar la configuració de KDE
Si el problema està en la configuració, el més senzill és eliminar-la i reiniciar la sessió. Tota la configuració personal de KDE està dins de la carpeta de l'usuari en un directori amb l'original nom .kde (que com tothom sap és oculta perquè el seu nom comença per un punt).
Per tant vaig tornar a obrir una consola i eliminar tota la configuració de KDE:
$ cd
$ yes | rm -R .kde
Un cop liquidada la configuració, només feia falta reiniciar la sessió amb CTRL+ALT+BACKSPACE
Això solucionava el problema però tenia el problema que es perdien totes les configuracions personalitzades dels programes de KDE (posicions de les icones, configuració de Kopete, ...) i a més s'ha de tancar la sessió per poder continuar treballant...
Una mala solució però en cas d'urgència i si no es troba res més ...
5. Segona solució: Liquidar només la configuració de kicker
El pas següent més lògic és en comptes d'esborrar tota la configuració de KDE, només esborrar la del kicker.
Per ara aquesta és la solució que he fet servir perquè no puc anar més enllà per investigar què és el que provoca que la barra peti fins que no em torni a passar o sigui que per ara aquesta serà la solució optima.
Cal entrar en els directoris en que es guarda la configuració de kicker, esborrar-la i tornar a iniciar el programa (si ja està en marxa abans s'ha de matar perquè només n'hi pot haver un alhora)
$ rm ~/.kde/share/config/kickerrc
$ rm -R ~/.kde/share/apps/kicker
$ killall kicker
$ kicker
Així tot torna a funcionar perfectament i sense haver de tancar la sessió, però té el petit inconvenient que es perd la configuració de la barra i per tant hem de tornar a personalitzar-la. Però això és més molt més ràpid que tornar a configurar tots els programes de KDE.
Categoria: Linux | Fet per: Xavier | |
08/06: Fitxers de dades en KDevelop
Però amb el sistema de compilació/instal·lació de codi font més popular actualment, amb automake i autoconf, els usuaris estan acostumats a poder canviar el directori en el que s'instal·laran els fitxers (per exemple perquè no tenen permisos de root), això implica que definir el camí en un #define dins del nostre programa no és gaire bona idea.
Un usuari amb el configure pot definir en quin lloc s'instal·laran les dades en comptes de deixar el camí per defecte:
./configure --prefix=/home/federicu
Si fa això, el nostre executable ha de buscar les dades en el directori especificat en comptes de al directori per defecte!
Especificar el camí a les dades al compilar
Una forma interessant de solucionar això que permet Gnu C és la de definir constants en temps de compilació. D'aquesta forma si al compilar li passem el camí, l'executable no tindrà cap problema per trobar les dades independentment d'on s'hagin instal·lat.
Això es pot fer passant-li el valor al compilador amb el paràmetre -D. Vegem un exemple ràpid del que estic explicant:
Editem un fitxer prova.cpp amb el següent contingut:
#include
int main(int argc, char *argv[])
{
printf("%s\n",DIRECTORI);
return 0;
}
Com podeu veure, DIRECTORI no està definida en el codi font, per tant si compilem normalment ens dirà que no està definit. Però ara el compilem de la següent forma:
$ g++ -DDIRECTORI=\"/home/federicu/\" -o prova prova.cpp
Com podeu observar ara compila correctament i la execució d'aquest programa ens mostra el que hem especificat ("/home/federicu")
$ ./prova
/home/federicu/
$
Categoria: Programació | Fet per: Xavier | |
07/06: Empaquetat de codi font amb KDevelop
El programa que hem fet funciona molt bé des de dins del KDevelop (compila sense problemes) i fa l'empaquetat sense donar cap error, però quan intentem compilar el paquet generat falla estrepitosament en el make perquè per algun motiu no té en compte les llibreries que hem afegit nosaltres en les propietats del projecte.
És un problema amb el que ja m'hi havia trobat (i que encara em passa a la versió 3.4.1) però jo ja no hi faig gaire cas perquè ho soluciono mecànicament, però està clar que és un apartat que encara no està gaire ben solucionat i que als usuaris novells pot fer-los perdre els nervis.
La veritat és que es pot solucionar fàcilment.
1. Afegir la comprovació de les llibreries per l'autoconf
La idea general és que s'ha de donar la informació necessària a l'autoconf perquè sàpiga quines llibreries ens faran falta a l'hora de generar el make. (en concret li hem de dir quines llibreries hem de posar al enllaçar)
Per mi el més senzill és obrir el fitxer configure.in amb un editor de text i afegir-hi els paràmetres que fan referència a les llibreries. Això es pot fer amb qualsevol editor de texts normal, kate, gedit, ... però jo ho faig amb el millor editor del món, el joe (sempre havia volgut posar això a Internet :-))
$ cd projecte
$ joe configure.in
Per dir-li al autoconf que comprovi si una llibreria de desenvolupament està instal·lada en el sistema ho podem fer a través de la macro AC_CHECK_LIB. Aquesta macro ens permet fer dues coses: comprovar si l'usuari té instal·lades les llibreries necessàries o no ( i si posteriorment ens hi fixem al fer el "configure", veurem entre el piló de línies també hi surt la nostra) i afegir els paràmetres a la compilació.
El prototipus és el següent:
AC_CHECK_LIB(Llibreria,
funcio,
LIBS="$LIBS -lllibreria",
AC_MSG_ERROR([*** Missatge d'error!])
)
Posaré un exemple real per fer-ho menys pesat. Per exemple si volem que el configure comprovi si l'usuari té instal·lada la llibreria SDL_image i en el cas de que la tingui, afegeixi el paràmetre necessari per enllaçar el projecte, escriurem el següent:
AC_CHECK_LIB(SDL_image,
IMG_Load,
LIBS="$LIBS -lSDL_image",
AC_MSG_ERROR([*** SDL_image no trobada!])
)
En l'exemple IMG_Load és una funció de la llibreria SDL_image i pot ser canviada per qualsevol de les funcions que hi ha dins d'aquesta llibreria. A la variable LIB és allà on hem d'especificar el paràmetre d'enllaçat que necessita la llibreria i l'AC_MSG_ERROR és el missatge d'error que donarà el configure si falla perquè la llibreria no està instal·lada o la versió que té no té la funció que hem posat (jo poso els missatges d'error en català perquè sóc més xulo que ningú, però tothom els posa en anglès...)
Això ho hem de fer per totes les llibreries que el nostre projecte necessiti. O sigui una directiva AC_CHECK_LIB per cada llibreria que s'hagi d'incloure al compilar.
Només hem de vigilar una cosa: que afegim les línies abans de la línia AC_OUTPUT. Si afegim coses després d'aquesta no les farà perquè ja haurà generat el 'Makefile' abans de processar-les.
Categoria: Programació | Fet per: Xavier | |