Una pequeña dosis de autobombo y propaganda de un nuevo emprendimiento que estoy llevando a cabo… Se trata del servicio de Hosting y/o Diseño Web BBB (bueno, bonito y barato), que hemos dado en llamar Synaxis Hosting & Web Design .

Así que si usted, querido compuvidente, está buscando alguien que le diseñe la web de su empresa, su web de portfolio, ya sea una sencilla, austera y elegante página web, hasta una supreproducción en Flash envidiable por los directores más superproductores de Hollywood, pueden confiar en este humilde grupo de trabajo que poco a poco crece para ofrecerles las mejores opciones (y los mejores precios por supuesto).

No lo olviden, Synaxis Hosting & Web Design.

Fuente: Synaxis

Este post decidí escribirlo a raíz de las nuevas medidas que están a punto de aplicar en algún gobierno de Europa (léase el gobierno francés) que le permitirán revisar los contenidos de los e-mail, pasando por encima cualquier tipo de derecho a la privacidad que hasta hoy se intentaba reservar. La “excusa” es tan poco válida como el método que se pretende aplicar, ya que evitar que la gente comparta contenidos, por más que esto esté bajo derechos de autor, de copia, licencia de reproducción, etc…

Es como si uno tuviera que tener un policía delante  cada vez que le quiere prestar a un amigo un libro, un cd, etc. y si este contenido está bajo alguna licencia de copyright, aplicarnos todo el peso de la ley. Ridículo.

Menos aceptable aún, que tengan la posibilidad de leer todos y cada uno de los emails. Es decir, privacidad cero.

Pero la tecnología aún está de nuestro lado, y existe algo llamado encriptación, que mediante PGP y OpenPGP podemos usar cuando intercambiamos correos electrónicos.

Aunque si bien existen alternativas como PGP, voy a centrarme en hablar de OpenPGP y GPG, por ser opensource.

OpenPGP es un estándar de encripción de emails, basado en PGP (Pretty Good Privacy), que especifica la utilización de dos claves (una pública y otra privada). La clave pública es la que compartimos con aquellos que queramos compartir correos encriptados.

El software con el que podemos implementar la encripción es GPG también llamado GnuPG.

GPG cuenta con versiones para linux, mac os y windows, que pueden ser descargadas desde aquí.

Información sobre el uso de GnuPG aquí.

Fuentes:

• http://www.gnupg.org/
• http://www.gpg4win.org/
• http://www.infobae.com/contenidos/460248-100884-0-Pol%C3%A9mica-una-ley-Sarkozy-que-permitir%C3%A1-espiar-los-emails

Continuando con la seguidilla de artículos sobre el anuncio realizado por Google del desarrollo de un Sistema Operativo propio, y haciendo menos futurología, luego de investigar un poco por la net me topé con un foro de discusión público, donde el encargado del proyecto Native Cliente (NaCl) responde algunas dudas en torno a la relación entre este proyecto y Chrome OS.

En el mismo deja claro que si bien al ser el encargado de NaCl y no ser parte del equipo de Chrome OS, sus perspectivas a futuro son las de proporcionar mediante Native Client una capa de las que considera básicas en un sistema operativo: el entorno de aplicaciones. Èste implementado sobre una capa de abstracción de hardware (que muy bien puede proporcionar Linux).

A la vez de aclarar un poco el panoráma de Chrome OS (ya sabemos que usará el kernel Linux, que la clave de su entorno de aplicaciones es Native Client), deja una nueva duda al plantear su punto de vista sobre el manejo de recursos del sistema (hablando en general del browser corriendo sobre cualquier sistema operativo). Dice:

“La tercera función [de un sistema operativo], administración de recursos, es un poco especial. Mirando atrás parece una función del S.O., pero si miras hacia adelante y aceptas un modelo donde el hardware del cliente es barato e intercambiable, y donde los recursos viven en “la nube”, entonces esa primera afirmación se desmorona. Si la abstracción de recursos es distribuida, estos quizás necesitan ser administrados por algo como el navegador.”

Cómo le caerá esto último a Windows, Mac OS y GNU/Linux? Cederán la administración de recursos al navegador? Debemos estar atentos a los próximos anuncios de Google para ver como continúa la novela. A continuación la cita copy&pasteada del foro de discusión.

(texto completo en inglés)

I apologize that I can’t answer your questions more directly in this forum.
I think Google Chrome OS is a great project, but as I don’t manage it would
be out of place for me to speak on their behalf. And I’d rather not restate
what they have said.
What I think I can do is state explicitly what seems clear to me, from my
somewhat unusual perspective. Looking forward, I like to think of operating
systems as providing three basic functions:

- hardware abstraction
- resource management
- application environment

Of these three functions, Native Client focuses squarely on the application
environment. One of the things I like about the project is that we don’t
have to muck around with device drivers and such. I’m perfectly happy
letting existing operating systems, or eventually Google Chrome OS, take
care of the hardware abstraction function.

The third function, resource management, is a bit special. Looking back it
seems like an OS function, but if you look forward and embrace a model where
client hardware is cheap and interchangeable, and where resources live in
the cloud, then that assumption falls apart. If resource abstractions are
distributed, perhaps they need to be managed by something like a browser.

Brad

Fuente: http://groups.google.com/group/native-client-discuss/topics

Esta es la continuación del post: Como hacer tu propio Google Chrome OS (sólo para ansiosos y entendidos) – Parte 2 (Teoría).
Bienvenidos al laboratorio. Para este experimento vamos a necesitar lo siguiente:

Ingredientes

• Muchas ganas y tiempo
• Una distribución de GNU/Linux, la que más te guste
• Google Chrome OS
• Native Client
• Muchas ganas y tiempo

Instrucciones

Los invito a que participen activamente del desarrollo de Chromium (código libre del motor Chrome) y de Native Client. Es preferible usar esas ganas y tiempo en un proyecto grande y que puede llevarse acabo.

Con el misterio alrededor del nuevo sistema operativo Google Chrome OS de nuestro lado, no hay otra alternativa que imaginarse y suponer cómo puede llegar a ser el futuro competidor de Microsoft, Apple y por qué no todas las distribuciones basadas en GNU/Linux.

Luego de repasar información sobre algo que había anunciado Google hace unos meses, llamado Native Client, creo que puedo llegar a imaginarme algo más cercano a la realidad de lo que será el nuevo S.O.

Native Client fue ideado para funcionar en los navegadores actuales mediante un plug-in, y hablando mal y pronto vendría a ser algo similar a Flash. Aplicaciones descargadas desde la web por el equipo cliente que la visita, y luego ejecutadas y procesadas en el equipo local (a diferencia de las aplicaciones cliente-servidor, donde el procesamiento se realiza en el servidor y el equipo cliente solo recibe los resultados).

Hablando bien y tomándome un poco más de tiempo para explicarlo, se podría decir que Native Client, a diferencia de Flash, Javascript y Silverlight, no requiere de la ejecución de una máquina virtual para poder interpretar el código que descargamos. El código que recibimos es directamente interpretado por el hardware real, mediante instrucciones que “sobrepasan” al sistema operativo y van directo al procesador x86 ó ARM.

Native Client posee APIs (algo así como lo intermedio entre el código que escribimos en un lenguaje de alto nivel y las instrucciones aplicables al hardware luego de compilar) no sólo para el acceso a los principales componentes de la PC que utilicemos, sino también multimedia, que nos permitirá hacer uso de audio y video de forma nativa.

Todo enmarcado en un alto nivel de seguridad, que es en lo que más énfasis pone Google (recordemos el fraudulento Microsoft ActiveX, que con el tiempo entró en desuso debido a la facilidad de infiltrar código malicioso). Una de las formas de evitar algunas estrategias de inclusión de código indeseado es realizando un control del flujo de instrucciones en el código Native Client antes de su ejecución en el equipo local, validando que la aplicación no salga de las “barreras” de seguridad.

En febrero de este año Google liberó el código de Native Client y realizó un concurso en el que los participantes debían implementar mejoras de seguridad, entregando premios a las que consideraron más valiosas contribuciones.

Especificamente hablando de las aplicaciones, las mismas pueden ser desarrolladas en C o C++, en Windows, Mac Os y Linux, utilizando las herramientas de desarrollo que ofrece en su sitio. Luego de compilada la aplicaciòn, el archivo ejecutable adquiere la extensión .nexe (Network Executable). La ventaja de poder utilizar un lenguaje como C++, el más común para desarrollar aplicaciones tanto para Windows como para Mac o Linux, radica en la simplicidad que supone traducir programas ya existentes a la plataforma Native Client.

Hasta aquí vemos que toma la forma de un software bastante completo:

• Una plataforma que funciona sobre cualquier navegador (sólo basta con instalar un plugin).
• Permite utilizar aplicaciones desarrolladas en lenguajes de alto nivel de los que ya se ha hecho mucho uso.
• Ejecuta instrucciones en el equipo local directamente con mínima intervención del sistema operativo sobre el que corre.
• Tiene un robusto desarrollo en materia de seguridad y control de lo que se ejecuta.
• Velocidad en procesamiento de información, audio y video. Soporte de gràficos 3D mediante API O3D.
• Almacenamiento posible tanto en un servidor remoto como en uno local.
• Còdigo abierto. Libre. Gratuito.

Por todo esto, y remarcando en negrita lo más importante, Native Client ha sido el puntapié inicial de lo que han dado en llamar Google Chrome.

A este nuevo sistema operativo (al igual que al GNU de Stallman) le falta algo vital, algo básico para cualquier sistema operativo: el núcleo. Y aquí llega de nuevo, a la salvación, y qué mejor compañero de un código libre que otro código libre, el kernel Linux.

Pero… Un momento! Tenemos el kernel (interfaz hardware/sistema operativo), tenemos las aplicaciones (interfaz shell o GUI/usuario), pero nos faltan dos ingredientes muy importantes: el S.O. propiamente dicho y el shell y/o GUI.

En cuanto al S.O., no hay ninguna razón por la cual Google tuviera la necesidad de reinventar la rueda, y tranquilamente podría estar basado GNU/Linux, que ya trae consigo shell, herramientas de compilación, controles del sistema,  etc. Esto es algo necesario ya que las aplicaciones correrán sobre el navegador Chrome, el cual debe correr sobre algún sistema operativo.

En cuanto al shell, ya lo tenemos, pero el usuario general, normal, no técnico, de un pc no es el principal amigo de los shell. Por lo que se necesita un GUI, la forma amigable del shell, por así decirlo. Sobre GNU/Linux existen actualmente varios GUI, llamados Administradores de Escritorios/Ventanas. Los ejemplares más conocidos son: KDE, Gnome.

KDE y Gnome se caracterizan por ser amigables, bonitos, tienen efectos 3D, pero en cuanto a rendimiento se refiere, pierden la guerra contra gestores como Blackbox, por ejemplo, que consiste simplemente en un fondo de pantalla, y unos cuantos menúes sencillos. Cabe aclarar que todos estos GUI corren sobre un sistema gráfico llamado Xorg, sistema de las X, Sistema X, X, etc. Algunos seguidores de Apple (si no lo saben ya) quizás se pregunten si tiene algo que ver con el Mac OS X y la respuesta es: sí. Mac está basado en varios componentes de GNU/Linux, pero ese es otro tema… o no?

No dudo de la capacidad de los desarrolladores de Google (presentes y futuros) de programar desde cero un entorno gráfico (llamemos a esto fondo de pantalla, ventanas, escritorios, barra de tareas, etc.) basado en X. La principal diyuntiva es sí han optado por instrumentar un GUI directamente mediante X (utilizando el código nativo tradicional), o un GUI totalmente Native Client.

Siguiente >>

Si te interesa saber más sobre Cómo hacer tu propio Google Chrome OS, seguí leyendo la 2da parte haciendo clic acá.

Fuentes:

• Genbeta: Native Client codigo nativo desde el navegador
• Google Code
• Google Code: O3D
• Stanford en Youtube: Native Client: Native Code for Web Apps

Si bien este blog es sobre informática y tecnología, y poco tiene que ver con la política, me gustaría ocupar un pequeño espacio, al menos un artículo, haciendo referencia a uno de los hechos que nos rodea y que está ocurriendo en este momento.
No puedo darme el lujo de mirar para otro lado y disimular la realidad en la que vivo. Sobre todo si es algo que sucede geográficamente tan cerca y que afecta directamente a mi planeta, a mi continente y a mi país, por qué no decirlo.
Más que en la explicación de cómo ocurrió, cuales fueron los medios que llevaron al golpe de estado en Honduras, voy a centrarme en las consecuencias, en cómo se está desarrollando y a donde creo que puede llegar todo esto. De todas formas, como breve reseña, paso a explicar lo sucedido en hechos concretos: en Honduras el presidente electo democráticamente en el 2006, Manuel Zelaya. tuvo la intención de llamar a referéndum para permitir la reelección de presidentes, repartiendo urnas en todo el país para que todos los ciudadanos puedan participar del mismo. Para dicha tarea, solicitó al jefe militar del estado, Roméo Vásquez, que ponga a disponibilidad personal militar para controlar los comicios y asegurar los derechos de los votantes. Éste se negó, a lo que Zelaya respondió destituyéndolo de su cargo.

Utilizando las palabras “un jefe militar no abandona el puesto hasta que entrega el bastón de mando”, Vásquez se negó a aceptar la destitución, la cual la Corte Suprema no avaló, dejándola en suspenso. Luego, la Corte Suprema decidió ordenar la readmición del jefe del estado mayor de las fuerzas armadas, y declaró ilegal la realización de un referéndum, ya que modificaría el contenido de la Carta Magna, un hecho, según argumentación de la justicia, anticonstitucional.

El fin de esos días de disputa y recelo entre el Presidente Zelaya y el jefe militar Vásquez, se dio con la toma del poder por parte de las fuerzas armadas, el 25 de junio del presente año. Algunos medios lo calificaron como golpe de estado cívico-militar.

Ahora bien, vale aclarar que la falta de garantía de 5 derechos constitucionales de los ciudadanos durante el toque de queda establecido por el nuevo gobierno de facto, pareciera ser, o al menos yo lo considero, también inconstitucional, por lo menos. En resumidas cuentas, durante el toque de queda, las personas que salen a la calle pueden ser maltratadas, detenidas , secuestradas e incluso asesinadas, por cualquiera, incluso (y sobre todo) las fuerzas del estado.

Opiniones acerca de si es bueno o no para Honduras el golpe de estado aparte, ya que eso deben decidirlo los propios hondureños, yo no estoy de acuerdo con el golpe, y creo que va a ser perjudicial para América Latina y para mi país, Argentina, si prosigue y no se frena.

Muchos hablan de que este golpe es un “laboratorio”, una prueba de procedimientos a aplicar en otros países del territorio. Si esto es así, creo que al menos deberíamos estar atentos, ya que suena bastante alarmante. He leído por ahí que Guatemala así como el Salvador podría ser el siguiente objetivo (si algún salvadoreño o guatemalteco nos lee, me gustaría tener su opinión y que nos cuente cómo se vive esta situación allá).

No sería de extrañar que haya personas, empresas y gobiernos en desacuerdo con la “izquierdización” aparente de latinoamérica, y a los cuales un golpe militar que aplique políticas más capitalistas beneficiaría. Además, no olvidemos que el capitalismo está en crisis, y hay que encontrar culpables. Acaso no sean “estos gobiernos de izquierda”…

Si el plan que se intenta llevar a cabo puede ser frenado, el socialismo revolucionario podría dar un gran paso, al no sólo reafirmarse en latinoamérica sino también repercutir en la política y economía internacional, invitando a otros continentes a sumarse a una reestructuración socioeconómica.

Con ésta última esperanza yo me quedo, y me uno a todos los que estén en contra de este y cualquier golpe de estado que atente contra la libertad de las personas.

Este post es la continuación del artículo Guia rápida para crear un sitio en PHP con CakePHP #1 .

Instalación sencilla de Apache + PHP + MYSQL en Windows

No soy partidario de Windows, pero a veces sólo se tiene acceso a una PC con Windows para desarrollar. Para esos casos se puede instalar el paquete XAMPP: http://sourceforge.net/projects/xampp/.

Luego de descargarlo, lo instalamos o descomprimimos en una carpeta, según sea el caso, y vamos a tener una herramienta llamada XAMPP Control, que al ejecutarla nos mostrará el estado de Apache, Mysql, Filezilla y Mercury; unos botones para iniciar y terminar (Start/Stop); y un botón para configurarlos (Admin).

Por ahora sólo necesitaremos iniciar Apache y MySQL.

Mod_rewrite

En la primera parte de este tutorial, repasamos la instalación de lo que necesitamos para empezar a desarrollar nuestro sitio con CakePHP.

Un módulo muy importante es el mod_rewrite, que se encarga del manejo de las URL “virtuales” que vamos a utilizar en nuestro sitio para automatizar varias cosas. Este módulo es vital para CakePHP y casi vital para cualquier otro framework de desarrollo web.

Para activarlo debemos editar el archivo httpd.conf de Apache, y descomentar la línea LoadModule rewrite_module modules/mod_rewrite.so

Más info sobre mod_rewrite en el blog linkalicante.

Instalación de CAKEPHP

Ya está todo listo, ahora descomprimimos la versión de CakePHP [Descarga] en nuestra carpeta root del servidor web (en Linux: /var/www, en Windows: xampp/htdocs/) .

El Modelo MVC (Model, View, Controller)

El modelo MVC es utilizado por varios frameworks, entre ellos CakePHP, por eso lo vamos a explicar un poco de que se trata.

Model (modelo), View (vista) y Controller (controlador) son los componentes en los que nos basaremos para construir nuestras páginas.

En primer lugar el Model es lo que vincula nuestra aplicación con una determinada tabla en la base de datos, que llamaremos con un nombre en plural, por ej. ejemplos. Los modelos son archivos .php que se ubican en la carpeta /app/models/ de CakePHP, y en los mismos encontraremos la definición de una clase que oportunamente por defecto debe llevar el mismo nombre que la tabla, pero en singular, por ej. Ejemplo. En el modelo también definimos las validaciones que podría llegar a hacerse y los foreign key que vincularán nuestra tabla con la tabla de otro modelo.

Después nos encontramos con el Controller (Controlador), que es lo primero que es ejecutado cuando el navegador/cliente web  solicita una página al servidor web. Aquí va toda la lógica de la página, las funciones, el envío de una vista para ser mostrada en el navegador, entre otras cosas. Los controladores son archivos .php almacenados en la carpeta /app/controllers/ y llevan en su nombre el formato ejemplos_controller, es decir, el nombre en plural seguido de la palabra controller.

La View (vista) es la plantilla que usaremos para mostrar nuestros contenidos. La misma es un HTML que embebe PHP para mostrar los datos enviados por el controlador, así como para devolverle al controlador datos que ha ingresado el usuario desde el navegador. También permite utilizar PHP embebido para generar código HTML de manera automática (en CakePHP los objetos utilizados para este proposito son llamados Helpers).

Algo que debemos tener en claro antes de empezar a desarrollar, es que el código es CaseSensitive, discrimina mayúsculas y minúsculas, y lo más recomendable es seguir las convenciones de CakePHP para los nombres de tablas, vistas, controladores y modelos.

En la próxima entrega del tutorial, crearemos un ejemplo simple de aplicación en CakePHP.

Me encuentro testeando el WordPress 2.8… Luego les cuento como va la cosa.