jueves, 1 de diciembre de 2011

Distribuir energía en Corriente Contínua, DC, y en baja tensión para grandes consumidores.


 Leemos en "Data Center Knowledge" que revivió la discusión DC vs AC.

Hace un siglo y medio se discutió sobre si debería distribuírse la energía eléctrica en la forma de corriente contínua o alterna, DC y AC respectivamente (War of currents).

En aquella oportunidad se impusieron los criterios mejor estudiados de los que impulsaron la AC. Hasta hoy, la forma más eficiente, versátil y abarcativa de transmitir y distribuir energía es en la forma de AC.

Pero los tiempos cambian, y hoy en día tenemos industrias que no dependen tanto de sistemas electromagnéticos con motores u otra maquinaria trifásica. Tal es el caso de los Data Centers. Los Data Centers albergan computadoras, discos duros y equipos electrónicos para redes informáticas. Todos estos equipos funcionan con DC, y desde el Lawrence Berkeley National Labs se aboga por el uso de DC como sistema de distribución de energía para Data Centers .

Personalmente creo que, debido al desarrollo de luminarias leds con 4 veces mejor rendimiento que las luminarias convencionales, el alumbrado público y doméstico también experimentará un retorno a la discusión DC vs AC. Pero esta vez con nuevos argumentos y un nuevo actor, la luz LED.

jueves, 4 de agosto de 2011

PHP y MySQL . Los caracteres á é í ó ú Á É Í Ó Ú se muestran como á é í ó ú Á É Í Ó Ú

Como programador te habrá pasado que al escribir en un formulario la letra á, esta queda guardada en MySQL como á .
Seguramente tomaste los siguientes recaudos:

- Las páginas html generadas por PHP tienen el encabezado
< meta equiv="content-type" content="text/html;charset=utf-8" >


- La tabla en MySQL tiene el campo
character_set_client = utf8


Con todo, la letra á sigue guardándose como á, aunque en la página generada se vea bien.

La solución a este odioso problema es muy simple, como indica http://www.papascott.de/archives/2007/05/05/corrupted-utf-8-characters-with-php-and-mysql/ :

- Inmediatamente después de cualquier conexión hecha con "mysql_connect", hay que agregar la instrucción
mysql_query("SET NAMES 'utf8'")

Ahora sí, los datos serán guardados en MySQL en correcto utf-8 .

sábado, 18 de junio de 2011

País altamente industrializado o solo agroindustrial

Leemos en el libro "El mito agrario" (Federico Bernal, 2010, colección Claves para todos, editorial Capital Intelectual www.capin.com.ar), sobre la cuestión de tener un país manufacturero de productos de alto valor agregado o solo materia prima, que ya en 1876 Vicente Fidel López decía

"(...) llamo la atención de los señores Diputados sobre la situación difícil en que se encuentra nuestro país (...) ¿y por qué? Y esto es así porque no sabe manufacturar las materias primas que produce (...) nosotros tenemos nuestro desierto: pero nuestro desierto se agota tanto más cuanto que está habitado por gente que no trabaja, y yo le diré al Sr. Ministro por qué es que no trabajan; es porque cuando se tiene una extensión de veinte leguas que da una excelente renta al capitalista se la da a condición de tener la tierra y el país despoblado (...) es necesario que vayamos poblando nuestros inmensos campos y radicaremos menos (...) en la teoría de Azara que quería siempre el desierto con cuarenta mil habitantes y cuarenta millones de vacas. La República Argentina cuando tenga cuarenta millones de habitantes (que algún día no lejano los llegará a tener) no ha de poder tener desiertos para doscientos cuarenta millones de ganados, y aquel número de habitantes no lo podremos tener sino a condición de que seamos ricos por el trabajo. ¿Y sobre qué vamos a trabajar? Sobre nuestras materias primas precisamente". (Cámara de Diputados de la Nación, 18 de agosto de 1876).

Curiosamente, para el año 2010 Argentina tenía ya 40 millones de habitantes y a las vacas las tienen los mismos dueños de hace un siglo.

jueves, 26 de mayo de 2011

¿Cómo elegir una lámpara de bajo consumo?

En Argentina se prohibió mediante Ley 26.473 la importación y comercialización de lámparas incandescentes. La ley entrará en plena vigencia el 31 de mayo de 2011.

Pero, ¿cómo elegir una lámpara de bajo consumo, habiendo tantos modelos, potencias y marcas?. Comprar una lámpara incandescente resultaba fácil porque son muy baratas, y elegir mal no implica un gasto que lesione el presupuesto doméstico; si la lámpara incandescente falla, se compra otra, y listo.

En el Instituto Nacional de Tecnología Industrial de Argentina, INTI ( http://www.inti.gob.ar ), se probaron lámparas de bajo consumo de distintas potencias y marcas. Los resultados pueden consultarse en http://www.inti.gob.ar/sabercomo/sc45/inti3.php . El informe completo puede bajarse de http://www.inti.gob.ar/ambiente/inf-tec.pdf .


martes, 20 de octubre de 2009

La estafa del voto electrónico

Según leemos aquí (http://www.dailykos.com/storyonly/2009/10/20/795343/-Sequoia-Voting-Systems-hacks-self-in-foot), una empresa que fabrica máquinas para voto electrónico dejó expuesto código SQL que manipula los datos de las elecciones.

Por si esto no se entiende en un primer momento, lo que se descubrió es que el código SQL almacenado en las máquinas de voto electrónico no solo almacena y cuenta los votos, si no que además realiza tareas que están siendo investigadas. Según las leyes de EEUU, estas tareas adicionales estan prohibidas, pero la ciudadanía no tiene forma de auditar las máquinas, ya que los mecanismos de funcionamiento son considerados secreto industrial.

El voto electrónico es la última moda en métodos de estafa a los pueblos. Entre otros puntos, el voto electrónico:
- Impide un recuento de los votos
- Registra la identidad del votante y su elección
- Traslada la tarea del conteo de votos a una empresa privada, cuando esta tarea tiene que estar en manos de los ciudadanos que conforman las mesas electorales

Para informarse más acerca del voto electrónico, visite http://www.electronic-vote.org/

domingo, 28 de diciembre de 2008

Trabajando con microcontroladores de Microchip en GNU/Linux y Windows

Microcontroladores PIC de Microchip

Debido a su precio y disponibilidad, los microcontroladores PIC de Microchip son muy populares. Con estos microcontroladores es posible atender todas las aplicaciones de electrónica para consumo imaginables, desde equipos para al automotor, automatizaciones industriales, juguetes, instrumentos para laboratorio y hasta equipos usados en medicina.

Herramientas multiplataforma para la programación de PICs

Para programar un PIC necesitamos de 2 herramientas de software y una herramienta de hardware:
  • Un lenguaje ensamblador, que convertirá nuestro código fuente de ensamblador a código máquina de PIC. Además del lenguaje ensamblador, existen lenguajes de alto nivel basados en C, Basic y Pascal que permiten reducir el tiempo de desarrollo de software para PICs.
  • Un software programador, o software para transferir el programa en código máquina desde la PC hasta el PIC
  • Un programador de PIC. Este es el hardware encargado de vincular la PC con el PIC al momento de transferir el programa desde la PC al PIC. Algunos modelos de programadores permiten monitorear el estado del PIC en cada instrucción.

Lenguajes ensambladores

El mejor lenguaje ensamblador para PIC, desde el punto de vista técnico y por su licencia de uso, es el ensamblador gpasm, incluído en la suite GPUTILS. Esta suite de software contiene todo lo necesario para escribir software en lenguaje ensamblador. Funciona en Unix (incluído GNU/Linux), Mac OS X y Windows.

Lenguajes de alto nivel

Un lenguaje de alto nivel muy bueno, ya que permite extender las funcionalidades del lenguaje a nuevos modelos de PIC, es el compilador Jal v2. Entre otras cosas, este lenguaje permite realizar operaciones aritméticas de 16 bits, algo engorroso de lograr en lenguaje ensamblador. Está basado en Pascal, pero en su estructura pueden reconocerse elementos de C y de Basic. Cuenta con versiones para GNU/Linux (x86) y Windows.

Software programador

Por su licencia y su disponibilidad en GNU/Linux y Windows, el mejor software para programación es el pp06. Funciona con la mayoría de los circuitos programadores.

Hardware de programación, circuito programador, o simplemente programador de PIC

El circuito más común es el de David Tait. Debido a su simpleza, y a que es posible adaptar el programador a los nuevos modelos de PIC, en internet se encuentran muchas variantes de este programador. Recomiendo esta versión.

Simuladores de PIC

Si bien Microchip provee de una herramienta gratuita para la simulación de PICs, el MPLAB, este no funciona en GNU/Linux. Por esto, el mejor simulador de PICs multiplataforma es el gpsim.

Otros recursos

Para explorar otras herramientas de software y hardware, visitar GNUPIC.

martes, 16 de diciembre de 2008

Particiones swap en sistemas virtualizados

El tamaño de la partición "swap"

Una de las preguntas más comunes en los foros sobre GNU/linux es ¿qué tamaño tiene que tener la partición swap?. No hay una respuesta clara a esa pregunta, porque el tamaño de la partición swap depende exclusivamente del uso que se le dé a la computadora.

Como regla general, para una computadora que se vá a usar en un oficina, 512Mb de RAM real y una partición swap de 1Gb cubren todas las necesidades corrientes. Si se tiene 1Gb de RAM, 512 de swap harán el trabajo. Si se tiene más de 1Gb de RAM es poco probable que se utilice el área swap.

Programas que realizan cálculos usarán más RAM según el volúmen de datos y cálculos que se realicen. En este caso, conviene consultar exhaustivamente los manuales del programa para estimar la cantidad de RAM a usar, ya que sí es posible estimar previamente el volúmen de datos involucrados en el proceso.

Cada vez es más común encontrar ambientes en donde la mayoría de los sistemas operativos que componen la infraestructura informática no corren sobre hardware real, sino sobre hardware virtualizado. Esto complica las decisiones acerca del tamaño de las particiones swap.

En sistemas virtualizados, tenemos que el sistema HOST (aquél que alberga el software de virtualización) posee una RAM real y un área de intercambio. Los sistemas operativos GUEST (aquellos que están siendo virtualizados en el sistema HOST) cuentan con una RAM "real" (virtualizada por el HOST) y una partición swap (también virtualizada por el HOST).


El tamaño de la partición swap en sistemas virtualizados


Para hechar luz sobre criterios de decisión acerca del tamaño del área de intercambio (swap) de los sistemas virtualizados, realicé el siguiente experimento:

Sistema HOST:
Debian GNU/linux 4.0 i386, sobre P3 733Mhz, 390Mb de RAM, 1Gb swap

Sistema GUEST:
Debian GNU/linux 4.0 i386, 640Mb de RAM, 96Mb swap

Software de virtualización: VirtualBox 2.0.2

Como se vé, el sistema GUEST tiene asignada más RAM real de la que el sistema HOST posee. Esto provocó que el sistema HOST utilice totalmente la memoria real y parte de la memoria de intercambio.

Hasta aquí la respuesta del sistema no trae sorpresas. Lo que sí resultó inesperado (al menos para mí) es que una vez que apagué el sistema GUEST, y con el servidor de virtualización aún corriendo, no se liberó la memoria que se había solicitado al sistema HOST. Pensándolo bien, esto no es tan inesperado. Tiene sentido, ya que los sistemas GUEST pueden volver a encenderse en cualquier momento de manera no determinista (mediante scripts activados remotamente, por ejemplo).

Si hubiera empezado a correr otras aplicaciones en el sistema HOST sin apagar el servidor de virtualización, el rendimiento de la máquina real hubiera sufrido de esta falta de memoria real, ya que los procesos de intercambio se hubieran incrementado en frecuencia y en tamaño de memoria intercambiada. Otros sistemas virtualizados en la misma máquina hubieran sufrido severamente esta falta de memoria real en el sistema HOST.

Conclusiones

Si se ván a virtualizar varios sistemas GUEST simultáneamente, conviene delegar a cada sistema virtualizado la administración de su propio espacio de intercambio. Esto es, debe asignársele a cada sistema GUEST una swap de tamaño suficiente e independiente. Si bien esto provoca lesiones en el rendimiento, ya que los accesos a disco para leer y escribir del swap es más lento que leer de la RAM real, el sistema HOST no sacrificará su propia swap para mantener la demanda de los sistemas GUEST.

Para optimizar aún más el rendimiento de las máquinas virtuales (y en consecuencia el rendimiento de la máquina real), convendría además asignar un disco virtual de tamaño fijo exclusivamente para swap en cada máquina virtual. Si se usara un disco virtual de tamaño dinámico (método corriente) para que el sistema GUEST aloje sus particiones de sistema y swap, el rendimiento sería mucho menor, ya que se usarían muchos recurso del HOST solo en redimensionar dinámicamente la partición del GUEST. Yendo más lejos en las optimizaciones, podrían usarse discos reales exclusivamente para uso como área de intercambio de los sistemas GUEST.

Como se dijo antes, solo el uso indica cuáles son los tamaños ideales para el área de intercambio.