«Sin la Verdad, la ciencia puede llevar a la destrucción del hombre y del mundo.»
Joseph Alois Ratzinger aka Benedicto XVI, Papa de Roma. Con ciertos matices podríamos estar de acuerdo en ello, pero la religión tiene los mismos efectos y la diferencia entre ambas está en que los científicos tienen un planteamiento crítico sobre la realidad y la verdad mientras que los religiosos creen siempre por dogma que están en posesión de la misma.
Desde el año pasado y según la orden del ministerio de la presidencia, el día 8 de septiembre es en nuestro país el día del cooperante. La fecha se escogió por coincidir con la Declaración del Milenio de las Naciones Unidas.
En las (por otro lado espantosamente mal diseñadas) páginas de la AECI (Agencia Española de Cooperación Internacional) tienes, si te interesa, información sobre eventos y actividades relacionadas con este día.
¡Por fin! Parecía mentira que el lector de RSS de una empresa basada en las búsquedas no implementara un buscador ¿verdad? No se si lleva ahí mucho más tiempo pero yo he reparado en el esta mañana. En el blog de markdbd apuntan además otras novedades.
Según el avance de las estadísticas publicadas por el Ministerio de Trabajo y Asuntos Sociales, entre enero y junio de 2007 ocurrieron en nuestro país 419 accidentes de trabajo mortales. El mismo día que Antonio Puerta perdió la vida un obrero de la construcción, contratado de forma irregular y que trabajaba en un regimen de semi-esclavitud, moría tras ser aplastado por un ascensor. Ayer martes seis trabajadores fallecían en otros tantos accidentes laborales…
¿No os parece que la diferencia de tratamiento es casi ofensiva?
Donde dije digo, digo Diego. La instalación de Asterisk que tenía pendiente ya está lista y operativa pero al final no he usado ni Asterisk Now ni una instalación manual sobre Debian como tenía pensado. Asterisk Now me resultó aún bastante verde y con muy poca documentación de soporte detrás suya como para apoyarte en el momento en que necesitas hacer algo fuera de las opciones más corrientes. Además el sistema de gestión de paquetes (rpath + conary) me resultaba bastante ajeno y, sinceramente, me daba pereza pelearme con él.
Pero cuando ya estaba a punto de pasar a la opción dos leí que existe otra distribución específica para montar una centralita con Asterisk basada en CentOS y que incorpora freePBX: Trixbox. Mano de santo, oigan.
El equipo que he montado usa una tarjeta Digium wildcard TDM400P con una línea analógica y una Junghanns quadBRI con dos RDSI (cinco canales en total) y da servicio por el momento a algo más de 20 extensiones sitas en la misma oficina dónde está el servidor aunque nuestra idea en breve es extender el soporte a otras oficinas en España. América y Africa de forma que realmente podamos sacarle partido a todos los beneficios de la VoIP (los usuarios en África, por ejemplo, podrían llamar y ser llamados a y desde teléfonos de nuestro país con tarifas locales). Los teléfonos que usamos son aparatos Thomsom ST2030, adaptadores Sipura para teléfonos analógicos convencionales y diversos SoftPhones.
La instalación ha sido engorrosa, no quiero engañar a nadie. En primer lugar debía de montarla sobre una máquina con una versión precaria de Asterisk montada sobre un Ubuntu Desktop y que estaba dando servicio así que me ha tocado hacerlo a ratos entre las 7.00 y las 9.00 de la mañana y sobre un segundo disco duro. En segundo lugar se trata de algo que tenía muy olvidado y hay conceptos de este tipo de instalaciones que es preciso tener muy claros, así que me ha tocado releer mucho sobre el tema. Por el momento no me siento con ganas de escribir un «paso a paso» como otras veces, así que no lo haré a menos que vea mucho interés en los comentarios. Lo que si me gustaría dejaros son algunas referencias para que, si tenéis interés, os sirvan para empezar:
Y, para terminar y darle un poco de color al post, un par de pantallazos de la interfaz web del sistema final:
El pasado viernes por la noche hubo una divertida fiesta de despedida del verano en el Bacchus, mi bar favorito en el barrio de Moratalaz, y muchos de los habituales del local nos disfrazamos como atormentadas ánimas para tal evento.
Y para muestra, algunas fotos:
El mes que viene me toca renovar el contrato con Dremhost, la empresa dónde está hospedado esta bitácora. En general estoy bastante satisfecho con ellos y, como comenté hace poco, gracias a los códigos de promoción no voy a tener que pagar ni un sólo céntimo. De hecho tengo acumulado crédito para los próximos tres años. No obstante la faena que me han hecho durante el verano me ha dejado tan mal sabor de boca que me estoy planteando la renovación con ellos. Os cuento.
Cuando volví de vacaciones hace un par de semanas me encontré que las visitas habían bajado una barbaridad. En un primer momento lo achaqué a las fechas, pero enseguida me di cuenta de que la cosa no era normal: prácticamente no había ninguna visita procedente de Google y todos sabemos que estas suponen el mayor porcentaje de las que recibe cualquier blog. Me acerco por las herramientas para webmasters de Google (¿qué no las conoces?¿y tienes un blog?¡ya tardas!) y compruebo que desde finales de julio el bot de google está recibiendo errores 403 cuando trata de acceder a mis páginas y, por tanto, está retirando los enlaces que tiene hacia ellas. Compruebo, además, que sólo ocurre con Un lugar en el mundo y no con ninguna otra de las webs o servicios que mantengo en la misma cuenta de hosting ¿Qué puede estar ocurriendo? Me pongo a hacer una revisión general y cuando le echo un vistazo al fichero .htaccess de la instancia web de este blog me encuentro que, ocultas tras varias decenas de retorno de carro para que pasen inadvertidas muy al final del fichero (¡qué truco tan sucio y tan viejo!) se encontraban las siguientes líneas que bloqueaban el acceso del bot de Google:
< Limit GET HEAD POST >
order allow,deny
deny from 66.249
allow from all
< /LIMIT >
Irritado les envíe un correo con la incidencia preguntando que había pasado y en la respuesta me negaron que esta manipulación haya sido cosa suya pero ¿de quién iba a ser? Máxime viendo lo que se dice por ahí sobre este tema. Esto es lo que me cuentan:
It is not policy to add the block that I found without notifying the account owner. That kind of block would only be added as an emergency measure since Googlebot sometimes doesn’t work properly (especially with dynamic sites like WordPress sites). Basically, it would have been added to prevent a server crash. Again, if a tech added it, you should have been notified since you can actually work with Google to fix the issue that might have caused their bot to misbehave. I have notified a tech lead of this and this will be dealt with appropriately.
Estoy de acuerdo con el tono y el contenido de la respuesta. Una empresa de hosting tiene todo el derecho del mundo para intervenir ante una instancia que comprometa el buen funcionamiento de unas de sus máquinas y que perjudique al resto de clientes que se hospedan en la misma. Tengo constancia de casos similares en este y otros hostings y nunca he protestado por ello. Pero siempre ha habido una comunicación inmediata de por medio diciendo algo así como «Existe este problema, creemos que lo causas tú y hemos actuado de tal forma de manera preventiva.» ¿Pero así de tapadillo, ocultándolo y sin comunicación alguna?¡Lamentable! En la siguiente gráfica podéis ver los efectos sobre el tráfico de estas páginas:
Hace meses que mi blog vuelve a estar libre de publicidad y no me siento perjudicado económicamente así que el problema que tengo con ellos no es ese, no… Pero la confianza es algo que, por definición, tarda en recuperarse y ahora mismo me siento un poco confuso y engañado… ¿Algún consejo?¿Les doy una segunda oportunidad o me largo?¿Conocéis alguna empresa de hosting con un programa de recompensas similar al de Dreamhost?
Desde hace unas horas estoy probando por aquí a Defensio, el nuevo plugin antispam para wordpress que por el momento permanece en fase de beta privada. He desactivado también los tres plugins que suelo usar de forma habitual para combatir el spam (Akismet, Trackback validator y Comment Policy) así que, si la cosa va mal, puede que temporalmente se vean por aquí mensajes poco apropiados… Ruego comprensión.
Así a primera vista tiene un aspecto bastante similar a Akismet. Defensio asigna un porcentaje de lo que el llama «Spaminess» a cada comentario recibido y guarda los mensajes que el considera spam en una página al mismo nivel que los Comentarios de tu wordpress. Además te permite a ti elegir que porcentaje (por defecto situado al 80%) se considera como spam de forma obvia y queda relegado a un segundo nivel. Mantiene, además, estadísticas no sólo con los mensajes de spam capturados sino también con los comentarios legítimos y los falsos positivos y negativos.
Ya os iré contando que tal aunque, me temo, que si el plugin no es todo lo bueno que debiera lo veréis vosotros mismos…
Mark Russinovich vuelve a bajar a la arena para defender a su patrón y explica detalladamente (en un artículo bastante técnico pero asequible) el porqué del descenso de rendimiento de Vista en las conexiones de red al reproducir música, reportado inicialmente en los foros de 2CPU y amplificado por Slashdot y Barrapunto.
El problema no está causado por el DRM como se ha apuntado por ahí y el bueno de Mark (si, si, le sigo tenido simpatía, que le voy a hacer) trata de convencernos de que la cosa no es tan grave y que está causada por un cúmulo de infortunios que se ha cernido sobre sus cabezas de forma imprevisible. Entre líneas, no obstante, se deja entrever perfectamente la enorme chapuza que hay tras este engendro que ya está destinado a repetir el estrepitoso fracaso de windows me.
ACTUALIZACI?N: Ricardo Galli también da su opinión sobre el tema y, ya de paso, una clase magistral sobre diseño de sistemas operativos.
Abrimos la sección técnica post-veraniega con un problemilla y su solución. Estoy estrenando portatil en mi nuevo trabajo (¿qué no sabíais que me cambiaba de trabajo? Bueno, ya os contaré más cosas en unos días) y mi Linux no es capaz de manejar correctamente la conexión inalámbrica. Reconoce el dispositivo como Broadcom Corporation Dell Wireless 1390 pero no es capaz siquiera de mostrarme las redes disponibles. El portatil en cuestión es un HP Compaq nx7300, un modelo baratito pero bastante resultón y con una buena relación calidad/precio.
Bien, lo primero que vamos a hacer, más por culturilla que por otra cosa, es aprender algunos comandos que nos resultaran útiles para recoger información de lo que está pasando:
josemaria@penique:/etc/modprobe.d$ iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
eth1 IEEE 802.11b/g ESSID:"" Nickname:"Broadcom 4311"
Mode:Managed Access Point: Invalid
RTS thr:off Fragment thr:off
Link Quality=0/100 Signal level=-256 dBm Noise level=-256 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
vmnet8 no wireless extensions.
vmnet1 no wireless extensions.
josemaria@penique:/etc/modprobe.d$ lspci -nn | grep Broadcom
02:0e.0 Ethernet controller [0200]: Broadcom Corporation BCM4401-B0 100Base-TX [14e4:170c] (rev 02)
10:00.0 Network controller [0280]: Broadcom Corporation Dell Wireless 1390 WLAN Mini-PCI Card [14e4:4311] (rev 01)
Gracias a Google nos enteramos, además de que mucha gente tiene problemas con este dispositivo, que el módulo que carga el kernel de Linux para su gestión se llama bcm43xx. En la web de berlios nos dicen además que el driver se ha desarrollado mediante ingeniería inversa porque Broadcom no da detalle alguno de sus chips (ya sabeis chicos: si la decisión de compra es vuestra y teneis alternativas nada de comprar productos de Broadcom). Vamos a comprobar que, efectivamente, estemos cargando ese módulo:
josemaria@penique:/etc/modprobe.d$ lsmod | grep bcm43xx
bcm43xx 126824 0
ieee80211softmac 31360 1 bcm43xx
ieee80211 34760 2 bcm43xx,ieee80211softmac
Vamos bien. Ahora descargamos el módulo y comprobamos que ya no está en uso:
josemaria@penique:/etc/modprobe.d$ sudo modprobe -r bcm43xx
Password:
josemaria@penique:/etc/modprobe.d$ lsmod | grep bcm43xx
josemaria@penique:/etc/modprobe.d$
Para evitar que este módulo se carge en sucesivos arranques de nuestro sistema tenemos que ir al directorio /etc/modprobe.d y allí editar el fichero blacklist y añadir al final esta línea:
# deshabilita la carga de bcm43xx
blacklist bcm43xx
Ahora necesitamos los drivers para windows del dispositivo. Para esto no debería de haber ningún problema: yo me los he bajado de la web de soporte de hp. Lo único que debemos de tener en cuenta es que deben de estar descomprimidos. Si los tenemos en un .zip, o un .exe debemos de extraerlos antes y guardarlos así en un directorio de nuestra máquina. A continuación instalamos ndiswrapper y, si estamos aburridos por hoy de la línea de comandos, ndisgtk (una interfaz gráfica para este).
Ejecutamos ndisgtk (en los menús suele situarse como «Windows Wireless Driver»), pulsamos el botón de «Install new driver» y navegamos hasta el directorio dónde hemos dejado los drivers windows del dispositivo. Debemos de seleccionar el archivo .inf que acompaña a los mismos (en mi caso bcmwl5.inf).
Como veis aparece que el hardware no está presente… no tengo ni idea de porqué pero el caso es que funciona. Si queremos hacerlo desde la línea de comandos:
josemaria@penique:/opt/driverswifi.d$ sudo ndiswrapper -i bcmwl5.inf
installing bcmwl5 ...
josemaria@penique:/opt/driverswifi.d$ ndiswrapper -l
bcmwl5 : driver installed
device (14E4:4311) present (alternate driver: bcm43xx)
josemaria@penique:/opt/driverswifi.d$ sudo ndiswrapper -m
adding "alias wlan0 ndiswrapper" to /etc/modprobe.d/ndiswrapper ...
Y ya. No olvidemos activar el wifi desde el portatil (si posee algún botón o interruptor para ello como es el caso de este modelo) y, si usamos kde y knetworkmanager, veremos que ya nos está localizando las redes próximas y que podemos conectarnos a ellas.
