/etc/network/interfaces:
auto br0
iface br0 net dhcp
bridge_ports eth0 eth1
bridge_stp off
bridge_fd 3
Responder
Por fin se me hizo: cambiar el Makefile de Superkb para usar gcc -std=c99 -pedantic-errors en lugar de -std=gnu99.
Lo que me impedía hacerlo era que uso algunas extensiones de GNU, BSD o POSIX que no se encuentran en el estándar C.
Yo no sabía, pero basta con añadir la línea
#define _GNU_SOURCE
o, según el caso,
#define _POSIX_C_SOURCE 2
al principio del código fuente y glibc reconoce y habilita las funciones que hagan falta.
Esto es un paso hacia adelante, pues ahora ya puedo usar un simple «grep» para ver en qué archivos están «solicitando extensiones».
Desafortunadamente aún falta bastante para llegar al ideal, pues sigo atado a las herramientas de GNU. Por ejemplo ¿qué pasa si trato de compilar sobre OpenSolaris? La última vez que lo intenté, resultó que el Makefile usa extensiones que dependen de gmake (una de ellas es el include no fatal). Pero si hubiera gmake, ¿compilaría?
Sólo hay una manera de saberlo… 😉
Introduction and motivation
I have always felt the EIGRP metric as being really overwhelming. I see values like «2820096» and instead of understanding it, I always end up asking what the hell does that number mean.
For example, in RIP:
R 192.168.0.0/24 [120/3] via 172.16.1.1, 00:00:15, FastEthernet0/0
Just by looking at the metric of «3» I immediately know what is means: there are three steps between the announced network and the router receiving the advertisement. Easy, right? «Understanding the number» makes it easy for me to manage and diagnose it.
In OSPF, the metric (cost) is still not as cumbersome as EIGRP’s. However, in the following example, can you identify what does «66» mean? For you, is it «just a number» that won over another because of its numerical value being lower? How do you know if the number is right or not?
O 192.168.0.0/24 [110/66] via 172.16.1.1, 00:00:82, FastEthernet0/0
This is a translation of my previous post Etiqueta en el citado de mensajes de e-mail.
Introduction
The most ignored Internet Etiquette rule is that of the posting style when replying to an e-mail message.
By «quoting» I mean the inclusion of a previous message in a new one (for example, a reply) with the intent of stating the relevance of the answer itself in the original context. I would say «Dan, I don’t know what are you talking about. Please quote the original e-mail in your reply next time in order to know what were you replying to.»
Almost every e-mail client do quote the original message in the reply, at least by default. That is good, and it contributes to the «netiquette», but its abuse has made it completely useless.
Este es un ejemplo de lo que NO se debe hacer al diseñar un software.
[Sun Dec 20 14:37:42 -0800 -- alvarezp@octavio:~/patch-test] $ ls -l total 24 -rw-r--r-- 1 alvarezp alvarezp 7127 Dec 20 14:37 slpcall.bak -rw-r--r-- 1 alvarezp alvarezp 7127 Dec 20 14:37 slpcall.c -rw-r--r-- 1 alvarezp alvarezp 7232 Dec 20 14:37 slpcall.c.2 [Sun Dec 20 14:37:43 -0800 -- alvarezp@octavio:~/patch-test] $ diff -u slpcall.c slpcall.c.2 > p [Sun Dec 20 14:37:57 -0800 -- alvarezp@octavio:~/patch-test] $ cat p --- slpcall.c 2009-12-20 14:37:36.000000000 -0800 +++ slpcall.c.2 2009-12-20 14:37:36.000000000 -0800 @@ -66,6 +66,11 @@ slpcall->slplink = slplink; + slpcall->wait_for_socket = FALSE; + slpcall->xfer = NULL; + slpcall->dc = NULL; + slpcall->branch = NULL; + msn_slplink_add_slpcall(slplink, slpcall); slpcall->timer = purple_timeout_add_seconds(MSN_SLPCALL_TIMEOUT, msn_slpcall_timeout, slpcall); [Sun Dec 20 14:38:00 -0800 -- alvarezp@octavio:~/patch-test] $ diff -u slpcall.bak slpcall.c # .bak is a backup of original [Sun Dec 20 14:38:19 -0800 -- alvarezp@octavio:~/patch-test] $ patch < p patching file slpcall.c
Hasta aquí, todo bien.
[Sun Dec 20 14:38:53 -0800 -- alvarezp@octavio:~/patch-test] $ cp slpcall.bak slpcall.c [Sun Dec 20 14:39:02 -0800 -- alvarezp@octavio:~/patch-test] $ mkdir x [Sun Dec 20 14:39:04 -0800 -- alvarezp@octavio:~/patch-test] $ mv slpcall* x/ [Sun Dec 20 14:39:06 -0800 -- alvarezp@octavio:~/patch-test] $ ls -l total 8 -rw-r--r-- 1 alvarezp alvarezp 410 Dec 20 14:37 p drwxr-xr-x 2 alvarezp alvarezp 4096 Dec 20 14:39 x [Sun Dec 20 14:39:08 -0800 -- alvarezp@octavio:~/patch-test] $ diff -u x/slpcall.c x/slpcall.c.2 > px [Sun Dec 20 14:39:20 -0800 -- alvarezp@octavio:~/patch-test] $ cat px --- x/slpcall.c 2009-12-20 14:39:02.000000000 -0800 +++ x/slpcall.c.2 2009-12-20 14:37:36.000000000 -0800 @@ -66,6 +66,11 @@ slpcall->slplink = slplink; + slpcall->wait_for_socket = FALSE; + slpcall->xfer = NULL; + slpcall->dc = NULL; + slpcall->branch = NULL; + msn_slplink_add_slpcall(slplink, slpcall); slpcall->timer = purple_timeout_add_seconds(MSN_SLPCALL_TIMEOUT, msn_slpcall_timeout, slpcall); [Sun Dec 20 14:39:22 -0800 -- alvarezp@octavio:~/patch-test] $ patch < px patching file slpcall.c.2 Hunk #1 FAILED at 66. 1 out of 1 hunk FAILED -- saving rejects to file slpcall.c.2.rej
¿La solución?
patch -p0 < px