El futuro de nuestros escritorios
Marcando los pasos de la evolución
GNOME, el revolucionario
¿Les dije que todo esto es Linux?
¿Les dije que todo esto es Linux?
Con fecha de lanzamiento programada para marzo del 2011, GNOME toma la punta en el concepto funcional de las interfaces gráficas con su nuevo GNOME Shell, que será completamente funcional y estándar en GNOME 3.0
Una interface gráfica orientada a las actividades, extremadamente pulida y simple, para no perder tiempo. Un salto de GNOME que obviamente hará temblar, no solo a KDE sino a Windows, y hasta al Leopard de la Mac.
Y la historia se vuelve a repetir. Como todas las innovaciones del mundo UN*X, y en los últimos años, de Linux, Apple y Windows copiarán este concepto y lo publicitarán como propio.
Volviendo a GNOME Shell, ya hay videos que explican perfectamente este concepto, por lo que me ahorraré palabras. Les dejo algunos.

Cuando entregamos un desarrollo podemos permitir que sea instalado en una cantidad indeterminada de máquinas o podemos entregar unidades, facturar cada una de las copias instaladas. Sin embargo, el control fue siempre unos de los puntos débiles de las licencias. Todo desarrollo es vulnerable, todo software es “crackeable”, solamente podemos hacer lo más duro posible el camino.
Hay varios métodos para controlar las licencias de software, una de las más populares es las que les contaré. Supongo que este método debe tener un nombre… puede ser… diría que seguro, pero no importa.
Básicamente tenemos que contar con una base de datos, un servidor con Apache y PHP con safe_mode = off
Creamos una tabla que tenga al menos dos campos para almacenar cadenas de texto, uno para almacenar un identificador único de cada copia de nuestra aplicación, y el otro para almacenar el identificador de la máquina donde está instalada dicha copia.
La copia, al instalarse, extrae el identificador de la máquina y lo envía al servidor junto con el identificador de la copia, el servidor almacena el identificador de la máquina en el registro donde se ubica el identificador de la copia, siempre que el campo de identificador de la máquina esté vacio (que sea la primer instalación). Cada vez que se ejecuta, extrae el identificador de la máquina y lo envía al servidor junto con su identificador de copia, si el servidor reporta que el par existe, continúa la ejecución, si no, se cancela.
Este método parece ser uno de los más seguros, sobre todo si los datos con el servidor se intercambian con un encriptado fuerte para impedir la posibilidad de la intercepción. Sin embargo, no todos nuestros clientes instalarán nuestro soft en máquinas con acceso a internet, de hecho, dentro de las empresas, lo más probable es que la máquina donde se instale nuestro soft tenga un acceso muy limitado o nulo a internet. En estos casos no queda otra posibilidad que la de intercambiar llaves, es decir, que el soft, en el momento de la instalación entregue llaves que el usuario nos enviará por eMail, y le responderemos con otra llave que el soft interpretará como válida, es decir: la validación se hará por eMail. Obviamente este método es menos seguro por que tendremos que almacenar el identificador generado en la máquina (obviamente fuertemente encriptado) y consultarlo en cada ejecución.
Pero me estoy diversificando, retomo el camino.
Estamos apuntando a PHP.
Para “ligar” nuestro código a una máquina específica, necesitamos obtener los datos de los componentes de hardware de esa máquina. ¿Por qué? Por que los componentes de hardware casi nunca cambian, mucho menos si tomamos los seriales del disco rígido donde se encuentra instalado nuestro soft o del procesador.
PHP es un lenguaje que no tiene acceso de bajo nivel al hardware que lo soporta, y como todo lo “fijo” en una máquina es hardware, es virtualmente imposible obtener un identificador de máquina con PHP, al menos que PHP esté corriendo con la opción safe_mode en off.
Entonces, ¿como obtenemos los datos del hardware?
Debemos ejecutar algún comando propio del sistema que nos brinde los datos necesarios.
Hay dos formas:
Uno de los comandos más comunes en todos los sistemas operativos que puede brindarnos algún dato de hardware es el de configuración de la interface de red, que nos mostrará la dirección MAC (identificador mundialmente único) de la/ placa/s de red. En Windows: ipconfig, en UN*X: ifconfig
Usaremos estos comandos por que son comandos utilizados por muchas aplicaciones y el sistema se basa en ellos para el correcto funcionamiento de las conexiones de red, esto significa que las posibilidades de que estos comandos sean reemplazados por comandos creados por un usuario para engañar a nuestro soft, son remotas. El sistema fallaría.
<?php
//***************************************************************************
// Para sistemas Windows
function extraerMACWindows()
{
// booleano para indicar que el siguiente campo es la MAC
$MACexiste = false;
// ejecutamos el comando y almacenamos su salida
$cadmac = `ipconfig /all`;
// almacenamos cada línea en un string del array
$macseparada = split("\n",$cadmac);
// recorremos cada línea del array
foreach ($macseparada as $valor)
{
// separamos cada línea en nombre y valor
$valorSeparado = split(":",$valor);
// leemos cada campo: nombre y valor
foreach ($valorSeparado as $linea)
{
// si es la dirección MAC…
if ($MACexiste)
{
// retornamos la cadena
return trim ( $linea );
}
// si en el nombre encontramos el título de la dirección MAC
// indicamos que el siguiente valor es la dirección MAC
$ttlEsp = “dirección física”;
$ttlIng = “physical address”;
if ( strstr ( strtolower ( trim($linea) ), $ttlEsp ) ||
strstr ( strtolower ( trim($linea) ), $ttlIng ) )
$MACexiste = true;
}
}
// si llegamos a este punto, hubo un error
// en la extracción de los datos
echo " ";
}
//***************************************************************************
// para sistemas UN*X
function extraerMACLinux()
{
// booleano para indicar que el siguiente campo es la MAC
$MACexiste = false;
// ejecutamos el comando y almacenamos su salida
$cadmac = shell_exec("/sbin/ifconfig");
// almacenamos cada línea en un string del array
$macseparada = split( "\n", $cadmac );
// recorremos cada línea del array
foreach ( $macseparada as $valor )
{
// separamos cada línea en nombre y valor
$valorSeparado = split ( " ", trim($valor) );
// leemos cada campo: nombre y valor
foreach ( $valorSeparado as $linea )
{
// si es la dirección MAC…
if ( $MACexiste )
{
// retornamos la cadena
return trim ( $linea );
}
// si en el nombre encontramos el título de la dirección MAC
// indicamos que el siguiente valor es la dirección MAC
if ( trim( $linea ) == "HWaddr" )
$MACexiste = true;
}
}
// si llegamos a este punto, hubo un error
// en la extracción de los datos
echo " ";
}
//***************************************************************************
function extraerMAC()
{
// para sistemas Windows
$mac = extraerMACWindows();
// para sistemas UN*X
$mac = extraerMACLinux();
if( strlen ( $mac ) > 0 )
return $mac;
else
return "ERROR";
}
//***************************************************************************
echo extraerMAC();
?>
Vuestra primer tarea de aquí en más es reducir las dos funciones extraerMACxxx() a una.
Recuerden que lo más importante de esto es que conviertan todo su código a bytecode, si no, estas funciones no tendrían sentido.

Hoy domingo, día de descanso en mis tareas laborales, solamente un fanático puede dedicarse a escribir un artículo sobre sus herramientas de trabajo. La programación y los sistemas son mi pasión, no me imagino viviendo en una sociedad donde no existan las computadoras… aunque… creo que a todos los que trabajamos en sistemas, si nos sacan las computadoras nos dedicaríamos a las matemáticas. Bueno, por lo menos no nos suicidaríamos.
Mientras suena Iván Noble, y con el servidor prendido, les voy a contar como proteger nuestro código PHP
Basta de “cháchara” decía el gordo embustero y vayamos al grano.
En una Web donde prevalecen los CMS, deberíamos proteger a muerte nuestro código PHP que nos da de comer. Pero ¿como proteger el código de un lenguaje interpretado? Simple: facilitándole el trabajo al intérprete.

Cuando el navegador Web realiza una petición de una página PHP, Apache le entrega la petición al intérprete PHP, este levanta la página peticionada, la convierte a bytecode, ejecuta ese bytecode y entrega el resultado a Apache para que lo entregue al navegador.
El intérprete convierte (pre-compila) el archivo PHP a bytecode para acelerar la ejecución. Este archivo bytecode es ilegible, y esto es lo que debemos conseguir para, de alguna manera, encriptar nuestro código.
Pre-compilando los archivos PHP, además de hacer ilegible nuestro código, aceleramos la ejecución al desligar al intérprete de la tarea del compilado.
Existen dos métodos completamente gratuitos y absolutamente confiables: Zend Optimizer+ y Monas Encoder. El primero solamente interpreta el archivo en bytecode, el segundo compila a bytecode y además interpreta.
Zend es la empresa creadora del lenguaje PHP. Zend ofrece un compilador a bytecode llamado Zend Guard a un costo de U$S 600 por año. Obviamente descartamos esta opción, pero todo zapato tiene su horma. Existe un sitio llamado Free PHP Encoder que convierte (de alguna manera) nuestro código a bytecode. En esta página podemos subir simultáneamente todos los archivos que queramos convertir a bytecode, el sitio nos devolverá nuestros archivos con variables que tienen asignados caracteres aparentemente aleatorios y un archivo llamado decoder.php (en bytecode) que distribuiremos con el resto de nuestro código. Los archivos generados por este sitio pueden serán interpretados por el Zend Optimizer+
Por otro lado, Zend se dio cuenta de los malabares que había que hacer para incorporar el Zend Optimizer+ a su Zend Server, por lo que en la nueva versión de su Zend Server CE incorporó por omisión el Zend Optimizer+
El Zend Server es un producto ideal para distribuir un servidor Apache+PHP de fácil y rápida instalación, tan fácil y rápida que cualquier usuario inexperto podía ponerlo en funcionamiento en 10 minutos. Incluso es el servidor perfecto para distribuir con los instaladores de nuestro software si nuestra aplicación requiere de un servidor Apache+PHP.
Monas es Trotsky para Zend. Es simple, liviano, más rápido que Zend Optimizer+ y gratuito! También te ceba mates y te despierta para ir a trabajar.
Si queres saber quién hizo este par de módulos, no te esfuerces, el autor dice “hmm … what should i said about my self ?” cuando preguntan por él. Solamente hay una dirección: bdnt.monas @ gmail . com
De la página de Monas, descargamos el archivo monas-v1.0-win32.rar para Windows o monas-v1.0-linux32.rar para Linux. La instalación y el uso no pueden ser más simple:
Esto es todo.
Si necesitamos distribuir un servidor Apache+PHP con nuestros programas, también podemos optar por xamplite, un conjunto muchísimo más liviano que Zend y no necesita instalador, descomprimimos y ejecutamos.
Existen otras formas de hacer nuestro código ilegible, se trata de los ofuscadores. Estos, en algunos casos reemplazan las cadenas no literales del usuario con cadenas alfanuméricas aparentemente sin sentido, otros utilizan funciones de encriptamiento del código, y como lógicamente se supone, el archivo resultante es una única función de desencriptado. Lo único que consiguen los ofuscadores es darle un poco más de trabajo al que quiera obtener el código original. Nada recomendable.
Les dejo algunos ejemplos para que vean los resultados:
Basta por hoy, salió el sol, 15º y muchas ganas de despejarme, sigamos en unos días. En la próxima vamos a ver como “ligar” nuestro código a una máquina específica para que no pueda ser distribuido sin nuestro permiso.

Lanzado en 1997, después del exitoso y aclamado Delphi, y con un entorno similar a éste. Muchos componentes de Delphi pueden utilizarse en C++.En 1999 Borland anuncio la versión 4.0, poco tiempo después anuncio que su producto hermano Borland C++ seria discontinuado en favor del C++Builder.En 2000 salió publicada la versión 5.0 y en 2002 la versión 6.0. Para aquella época las versiones de C++Builder salían un año o un poco más de su contraparte Delphi.En 2003 Borland publica C++BuilderX (CBX), que usaba el entorno de desarrollo (Galileo) de un producto hermano: JBuilder y tenia poca similitud con C++Builder o Delphi, pues proponía como framework a wxWindows (en lugar de OWL, OWLNext o VCL). Este producto estaba dirigido a grandes organizaciones y no tuvo mucha aceptación.Al final del 2004 Borland anuncio que continuara desarrollando el C++Builder e incluirlo junto con la suite de desarrollo de Delphi development suite, abandonando el C++BuilderX.Cerca de un año después del anuncio Borland publico ‘Borland Developer Studio 2006′ que incluía el Borland C++Builder 2006 que proveía un administrador de configuración mejorado y varias correcciones. Borland Developer Studio 2006 es un paquete que incluida Delphi, C++Builder, y C#Builder.En 2006 Borland’s Developer Tools Group, la división encargada del C++Builder, fue transformada en una organización independiente (subsidiaria) denominada CodeGear.En 2007 Borland publico C++Builder 2007, proveyendo completo soporte para la API de Microsoft Vista, soporte mejorado a ANSI C++, y hasta 500% más rápida performance en el proceso de compilación desde el IDE, suporte para MSBuild, arquitectura de base de datos DBX4, “VCL for the Web” que permite el desarrollo visual de aplicaciones AJAX, y la librería OWLNext. El soporte de la API de Microsoft Vista incluye aplicaciones ‘temadas’ y soporte a la interfaz Aero y Vista Desktop. CodeGear RAD Studio 2007 incorporo C++Builder 2007 y Delphi. También en 2007 Borland revivio la línea “Turbo” y lanzo dos ediciones “Turbo” de C++Builder: Turbo C++ Professional, y Turbo C++ Explorer (no disponible actualmente de CodeGear), basado on Borland C++Builder 2006.En 2008 CodeGear fue adquirida por Embarcadero Technologies, quien continuo el desarrollo.C++Builder 2009 fue publicado en Agosto del 2008, las características agregadas más importantes fueron el soporte completo a Unicode tanto en la VCL como en la RTL, adopción anticipada del standard C++0x, soporte al ITE (Entorno de Traducción Integrado), componentes Ribbon y la inclusión de la librería Boost.C++Builder 2010 fue publicado en Agosto del 2009, fue el primer entorno de desarrollo que incluyo soporte a Windows7, permitiendo desarrollar aplicaciones que soportan la interfaz ‘Multitouch’.Codegear ha anunciado sus planes de desarrollo que incluirían soporte a OSX y Linux.
NOTA: Borland, en el 2000 comenzó a soportar el desarrollo en Linux mediante su RAD Kylix.