Oracle Compra a Sun Microsystems

"Esto es lo que me apareció esta noche al visitar el sitio de Sun Microsystems. Aún no lo creo."

Después de unos muy interesantes intentos de negociaciones entre IBM y Sun Microsystems para que la primera adquiriera a la segunda, resulta que fue Oracle, el emperador de las bases de datos, quien terminó adquiriendo a la moribunda empresa de Sun Microsystems por nada más y nada menos que 7,400 millones de dólares.

La noticia completa la pueden leer en el mismísimo sitio de Sun, con lo cual podemos dejamos de pensar que es un hoax de mal gusto. Entre los detalles que aparecen en dicha nota mencionan que habrá una mejor integración entre ambos productos y que llevan bastante tiempo trabajando juntos por lo que los cambios serán para mejoría de los productos de ambos y una mayor integración entre estos.

Cuando era IBM quien estaba detrás de Sun yo visualizaba una futura integración entre los entornos de desarrollo de cada uno, creando una fusión que pudiera tomar la simplicidad de los asistentes y herramientas incorporadas en Netbeans y toda la flexibilidad y potencia de Eclipse y su gama de plugins pero ahora quiza podamos ver una mejor integración hacia el lado de la capa de acceso y transformación de datos.

Este tipo de acuerdos posiblemente vaya mas por la vía comercial, para salvar a un decadente Sun Microsystems que ya había perdido el 80% de su valor en la bolsa de valores en 2008 pero nos afecta directamente a los que trabajamos diariamente con sus tecnologías y esperamos siempre constantes mejoras sobre ellas, especialmente si estas se liberan bajo licencias Open Source. Una de mis grandes interrogantes es qué es lo que hará Oracle con MySql, teniendo ya su propio motor de bases de datos? o qué pasará con JDeveloper, el Entorno de desarrollo de Oracle? o las tecnologías de virtualización?

Esperemos que esto ayude a que los estándares de Oracle se vuelvan más abiertos, y a que Sun crezca en sus innovaciones de virtualización quizá apuntándole a un próximo Open Solaris residente en la nube o a mejores soluciones middleware para aplicaciones java.

Qué esperas tú de esta fusión y cómo crees que te afecte si es que trabajas con estas tecnologías?

Oracle Compra a Sun Microsystems

"Esto es lo que me apareció esta noche al visitar el sitio de Sun Microsystems. Aún no lo creo."

Después de unos muy interesantes intentos de negociaciones entre IBM y Sun Microsystems para que la primera adquiriera a la segunda, resulta que fue Oracle, el emperador de las bases de datos, quien terminó adquiriendo a la moribunda empresa de Sun Microsystems por nada más y nada menos que 7,400 millones de dólares.

La noticia completa la pueden leer en el mismísimo sitio de Sun, con lo cual podemos dejamos de pensar que es un hoax de mal gusto. Entre los detalles que aparecen en dicha nota mencionan que habrá una mejor integración entre ambos productos y que llevan bastante tiempo trabajando juntos por lo que los cambios serán para mejoría de los productos de ambos y una mayor integración entre estos.

Cuando era IBM quien estaba detrás de Sun yo visualizaba una futura integración entre los entornos de desarrollo de cada uno, creando una fusión que pudiera tomar la simplicidad de los asistentes y herramientas incorporadas en Netbeans y toda la flexibilidad y potencia de Eclipse y su gama de plugins pero ahora quiza podamos ver una mejor integración hacia el lado de la capa de acceso y transformación de datos.

Este tipo de acuerdos posiblemente vaya mas por la vía comercial, para salvar a un decadente Sun Microsystems que ya había perdido el 80% de su valor en la bolsa de valores en 2008 pero nos afecta directamente a los que trabajamos diariamente con sus tecnologías y esperamos siempre constantes mejoras sobre ellas, especialmente si estas se liberan bajo licencias Open Source. Una de mis grandes interrogantes es qué es lo que hará Oracle con MySql, teniendo ya su propio motor de bases de datos? o qué pasará con JDeveloper, el Entorno de desarrollo de Oracle? o las tecnologías de virtualización?

Esperemos que esto ayude a que los estándares de Oracle se vuelvan más abiertos, y a que Sun crezca en sus innovaciones de virtualización quizá apuntándole a un próximo Open Solaris residente en la nube o a mejores soluciones middleware para aplicaciones java.

Qué esperas tú de esta fusión y cómo crees que te afecte si es que trabajas con estas tecnologías?

Deprecated Code (Codigo Obsoleto)

Todo programador, se habrá (debería?) de encontrar mas de alguna vez con este termino: Deprecated (Obsoleto).

Y este termino es especialmente frecuente al usar frameworks, que de tan "robustos y seguros", ya se estarán volviendo obsoletos en si mismos. Un excelente lugar donde encontrar código marcado como obsoleto, es utilizando metodos viejoss en un framework "nuevo", por ejemplo, llamar metodos del JDK 1.4 en el JDK 1.6.

Este "atributo" (Obsoleto) que se le da al código fuente, se especifica cuando una clase, función o API ha perdido su importancia, y tiene tan poca importancia que no debería de ser usada en lo absoluto, y probablemente deje de existir en un futuro cercano.

"Java Doc que muestra una función marcada como 'Deprecated' (Obsoleta)"

La necesidad de marcar una función, clase, API... código en general, como obsoleto, surge del desarrollo natural del código, para adaptarse constantemente a las nuevas tecnologías, mejoras de lógica, etc...

Supongamos que tienes una librería muy popular, y cada 3 meses liberas una versión nueva. Y en cada versión nueva, añades funcionalidad adicional y modificas metodos, y reescribes otros. Como tu librería es muy popular, tienes que mantener cierta compatibilidad con las versiones anteriores, y por esa razón tienes que mantener código viejo... porque tienes que darle tiempo a los developers que migren su código y comiencen a usar las novedades que has añadido a tu código. Y claro, tu no quieres que los developers sigan usando los metodos antiguas, que solo mantienes por motivos de compatibilidad, entonces la solución, es marcar el metodo, clases, o código en general, como obsoleto. ¿Útil no?

"¿Cuantos developers tendrán el 'honor' de marcar como obsoleto el codigo de alguien más?"

Como ven, la actividad de marcar clases, métodos, etc... como obsoleto, resuelve muchos problemas. Las clases existentes que usan el API antiguo continúan trabajando bien, pero el compilador reconoce y avisa sobre los elementos marcados como obsoletos.
Además, marcar el código fuente como obsoleto, es una responsabilidad que todo BUEN programador debe asumir, especialmente: cuando se trabaja en equipo, y cuando muchos developers usan el código que tu haces...

"Un buen programador, siempre se hace responsable del código que escribe."

En Java la etiqueta @deprecated, marca como obsoleto el código que le sigue, vean el Java API Documentator Generator (JavaDoc) para más información sobre como usar esta etiqueta en su código. Y claro no solo esta la etiqueta @deprecated, también esta el tipo de "annotation" Deprecated. Y finalmente les comparto esta útil página, que tiene información de "Cuando y Como" marcar como obsoleto el codigo fuente.

Y tu, ¿alguna vez has marcado código fuente como obsoleto?

UPDATE: Por una importante sugerencia de Xtecuan, se renombraron todas las incidencias de la palabra "funcion" por "metodos".

coding programming programacion javadoc java deprecated obsoleto

Deprecated Code (Codigo Obsoleto)

Todo programador, se habrá (debería?) de encontrar mas de alguna vez con este termino: Deprecated (Obsoleto).

Y este termino es especialmente frecuente al usar frameworks, que de tan "robustos y seguros", ya se estarán volviendo obsoletos en si mismos. Un excelente lugar donde encontrar código marcado como obsoleto, es utilizando metodos viejoss en un framework "nuevo", por ejemplo, llamar metodos del JDK 1.4 en el JDK 1.6.

Este "atributo" (Obsoleto) que se le da al código fuente, se especifica cuando una clase, función o API ha perdido su importancia, y tiene tan poca importancia que no debería de ser usada en lo absoluto, y probablemente deje de existir en un futuro cercano.

"Java Doc que muestra una función marcada como 'Deprecated' (Obsoleta)"

La necesidad de marcar una función, clase, API... código en general, como obsoleto, surge del desarrollo natural del código, para adaptarse constantemente a las nuevas tecnologías, mejoras de lógica, etc...

Supongamos que tienes una librería muy popular, y cada 3 meses liberas una versión nueva. Y en cada versión nueva, añades funcionalidad adicional y modificas metodos, y reescribes otros. Como tu librería es muy popular, tienes que mantener cierta compatibilidad con las versiones anteriores, y por esa razón tienes que mantener código viejo... porque tienes que darle tiempo a los developers que migren su código y comiencen a usar las novedades que has añadido a tu código. Y claro, tu no quieres que los developers sigan usando los metodos antiguas, que solo mantienes por motivos de compatibilidad, entonces la solución, es marcar el metodo, clases, o código en general, como obsoleto. ¿Útil no?

"¿Cuantos developers tendrán el 'honor' de marcar como obsoleto el codigo de alguien más?"

Como ven, la actividad de marcar clases, métodos, etc... como obsoleto, resuelve muchos problemas. Las clases existentes que usan el API antiguo continúan trabajando bien, pero el compilador reconoce y avisa sobre los elementos marcados como obsoletos.
Además, marcar el código fuente como obsoleto, es una responsabilidad que todo BUEN programador debe asumir, especialmente: cuando se trabaja en equipo, y cuando muchos developers usan el código que tu haces...

"Un buen programador, siempre se hace responsable del código que escribe."

En Java la etiqueta @deprecated, marca como obsoleto el código que le sigue, vean el Java API Documentator Generator (JavaDoc) para más información sobre como usar esta etiqueta en su código. Y claro no solo esta la etiqueta @deprecated, también esta el tipo de "annotation" Deprecated. Y finalmente les comparto esta útil página, que tiene información de "Cuando y Como" marcar como obsoleto el codigo fuente.

Y tu, ¿alguna vez has marcado código fuente como obsoleto?

UPDATE: Por una importante sugerencia de Xtecuan, se renombraron todas las incidencias de la palabra "funcion" por "metodos".

coding programming programacion javadoc java deprecated obsoleto

La importancia de los procedimientos almacenados

En esta ocasión, me quiero concentrar en algo muy importante del inmenso mundo (y misterioso para algunos) de las bases de datos, quiero hablarles de: Los Procedimientos Almacenados.
Los procedimientos almacenados (conocidos también como proc, sproc, stopro, o SP's por sus siglas en Ingles) son subrutinas que están disponibles para las aplicaciones que acceden a una base de datos relacional. Los procedimientos almacenados están, como su nombre lo indica, almacenados en el diccionario de datos de la base de datos.

¿Para que existen?, ¿para que usarlos, si puedo tener mis consultas bien bonitas metida en mi código (como consultas SQL Ad-hoc)? Esas preguntas exactas me hice yo hace algunos años. Que pena ser tan ingenuo. Gracias a Dios desperté de ese "lapsus ..." y si bien, no lo se todo, lo que se, lo tengo que compartir.

El uso más típico de los SP (de ahora en adelante asi me estaré refiriendo a ellos, en vez de escribir Procedimientos Almacenados) es proveer una validación integrada en la base de datos, asi como proveer mecanismos de control de acceso a la misma.

Los SP son usados para consolidar y centralizar lógica que originalmente se implementaba en las aplicaciones.

Eso quiere decir, que en vez de tener una "clase", con una lista interminable de funciones que hacen esto:

static function String getConsultaUsuario(String usuarioid) {
 return "SELECT * FROM user WHERE userid = '" + usuarioid +"'";
}

...usted debería de tener una serie SP en su gestor de bases de datos, implementado como un API "consolidado y centralizado" (en la base de datos). Lo mismo sucede con muchas consultas SQL "grandes", o secuenciales: no podemos dejarlas regadas en el codigo, necesitamos moverlas a un solo lugar...

"MySQL también tiene procedimientos almacenados"

¿Por que? bien, enumerare solo algunas razones:

• El mantenimiento de las consultas SQL es mas sencillo, porque las consultas SQL están centralizadas en el gestor.
• La seguridad se enriquece utilizando SP's, debido a que un buen DBA (Administrador de Bases de Datos) únicamente proveerá una lista de procedimientos (bien tipificados y documentados) que el programador llamara de acuerdo a sus necesidades. Asi, relevamos al programador de preocuparse de verificar que los INSERT, DELETE, etc... estén "bien", lo aliviamos de la "carga" de manipular directamente la base de datos. Y dejamos esa lógica en donde debe de ir: en el gestor.
• Suponga que debe añadir una condición extra a la función de ejemplo "getConsultaUsuario", tendrías que cambiar la cadena que se retorna en la función, probar los cambios, compilar o publicar tu aplicación. Los SP se pueden modificar, sin necesidad de recompilar y hacer un deploy completo de la aplicación.
• Y lo más importante de todo, los procedimientos almacenados SIEMPRE serán más rapidos que una consulta externa. Si no lo son, es por dos motivos: a) No puedes escribir procedimientos almacenados, y/o b) El gestor de base de datos que estas usando es deficiente.

Entonces podemos observar dos ventajas inmediatas: Reducir la carga de mantenimiento de código SQL, y aumentar la velocidad de la aplicación.
La desventajas: Nos estaremos amarrando al gestor, y más de algún programador probablemente saltara por no poder "tocar" (manipular) directamente los datos en la BD. Esto no es necesariamente malo, pero más de alguno protestará.

Tengo que aclarar que no hay usar SP absolutamente todo el tiempo y en toda aplicación a desarrollar. Un caso practico para implementar SP en una aplicación, es en el que se tiene una sola base de datos, y diferentes módulos o clientes que se conectan constantemente a esta. ¿Se imaginan tener una lista de consultas en cada modulo o cliente que se conecta?, ¿Y si se modifica la base de datos?, ¿cuantas consultas y en cuantos lugares lo iremos a modificar?

"Los SP son parte de la Alquimia de SQL que usted debe conocer"

Los SP en general, serán realmente útiles (y aplicables) en caso de estar desarrollando aplicaciones robustas, de categoría empresarial, o para servicios que deben ser seguros, que posean alta disponibilidad y con vistas a ser escalables.

¿Y dónde aprendo, donde veo ejemplos, etc? ... como siempre, Google tiene la respuesta.
¿Y tú, estas utilizando Procedimientos Almacenados en tu Software?

La importancia de los procedimientos almacenados

En esta ocasión, me quiero concentrar en algo muy importante del inmenso mundo (y misterioso para algunos) de las bases de datos, quiero hablarles de: Los Procedimientos Almacenados.
Los procedimientos almacenados (conocidos también como proc, sproc, stopro, o SP's por sus siglas en Ingles) son subrutinas que están disponibles para las aplicaciones que acceden a una base de datos relacional. Los procedimientos almacenados están, como su nombre lo indica, almacenados en el diccionario de datos de la base de datos.

¿Para que existen?, ¿para que usarlos, si puedo tener mis consultas bien bonitas metida en mi código (como consultas SQL Ad-hoc)? Esas preguntas exactas me hice yo hace algunos años. Que pena ser tan ingenuo. Gracias a Dios desperté de ese "lapsus ..." y si bien, no lo se todo, lo que se, lo tengo que compartir.

El uso más típico de los SP (de ahora en adelante asi me estaré refiriendo a ellos, en vez de escribir Procedimientos Almacenados) es proveer una validación integrada en la base de datos, asi como proveer mecanismos de control de acceso a la misma.

Los SP son usados para consolidar y centralizar lógica que originalmente se implementaba en las aplicaciones.

Eso quiere decir, que en vez de tener una "clase", con una lista interminable de funciones que hacen esto:

static function String getConsultaUsuario(String usuarioid) {
 return "SELECT * FROM user WHERE userid = '" + usuarioid +"'";
}

...usted debería de tener una serie SP en su gestor de bases de datos, implementado como un API "consolidado y centralizado" (en la base de datos). Lo mismo sucede con muchas consultas SQL "grandes", o secuenciales: no podemos dejarlas regadas en el codigo, necesitamos moverlas a un solo lugar...

"MySQL también tiene procedimientos almacenados"

¿Por que? bien, enumerare solo algunas razones:

• El mantenimiento de las consultas SQL es mas sencillo, porque las consultas SQL están centralizadas en el gestor.
• La seguridad se enriquece utilizando SP's, debido a que un buen DBA (Administrador de Bases de Datos) únicamente proveerá una lista de procedimientos (bien tipificados y documentados) que el programador llamara de acuerdo a sus necesidades. Asi, relevamos al programador de preocuparse de verificar que los INSERT, DELETE, etc... estén "bien", lo aliviamos de la "carga" de manipular directamente la base de datos. Y dejamos esa lógica en donde debe de ir: en el gestor.
• Suponga que debe añadir una condición extra a la función de ejemplo "getConsultaUsuario", tendrías que cambiar la cadena que se retorna en la función, probar los cambios, compilar o publicar tu aplicación. Los SP se pueden modificar, sin necesidad de recompilar y hacer un deploy completo de la aplicación.
• Y lo más importante de todo, los procedimientos almacenados SIEMPRE serán más rapidos que una consulta externa. Si no lo son, es por dos motivos: a) No puedes escribir procedimientos almacenados, y/o b) El gestor de base de datos que estas usando es deficiente.

Entonces podemos observar dos ventajas inmediatas: Reducir la carga de mantenimiento de código SQL, y aumentar la velocidad de la aplicación.
La desventajas: Nos estaremos amarrando al gestor, y más de algún programador probablemente saltara por no poder "tocar" (manipular) directamente los datos en la BD. Esto no es necesariamente malo, pero más de alguno protestará.

Tengo que aclarar que no hay usar SP absolutamente todo el tiempo y en toda aplicación a desarrollar. Un caso practico para implementar SP en una aplicación, es en el que se tiene una sola base de datos, y diferentes módulos o clientes que se conectan constantemente a esta. ¿Se imaginan tener una lista de consultas en cada modulo o cliente que se conecta?, ¿Y si se modifica la base de datos?, ¿cuantas consultas y en cuantos lugares lo iremos a modificar?

"Los SP son parte de la Alquimia de SQL que usted debe conocer"

Los SP en general, serán realmente útiles (y aplicables) en caso de estar desarrollando aplicaciones robustas, de categoría empresarial, o para servicios que deben ser seguros, que posean alta disponibilidad y con vistas a ser escalables.

¿Y dónde aprendo, donde veo ejemplos, etc? ... como siempre, Google tiene la respuesta.
¿Y tú, estas utilizando Procedimientos Almacenados en tu Software?

FLISOL 2009

El Festival Latinoamericano de Instalación de Software Libre (FLISOL), es un evento organizado por comunidades de usuarios de Software Libre, para promover y difundir el uso de estas tecnologías. El FLISOL es un evento que se realiza de manera simultanea desde el año 2005 en todas las ciudades de latinoamerica que deseen participar. En el año 2008, de acuerdo a la wikipedia: "participaron más de 200 ciudades en 18 países de Latinoamérica."

El objetivo de este evento, es presentar el software libre de la mano de su representante más conocido: GNU/Linux, en sus distribuciones más populares como lo son Debian, Ubuntu, ArchLinux, Mandriva, OpenSuse, Fedora, Gentoo, Slackware, etc...
Y claro que no queda descartada la instalación de otras aplicaciones libres como lo son: OpenOffice.org, The Gimp, Pidgin, Blender, Eclipse, etc... y otros sistemas operativos libres: OpenSolaris, FreeBSD, OpenBSD, GNU/HURD, etc...

Durante el FLISOL, se imparten charlas, ponencias y talleres, sobre temas locales, nacionales y latinoamericanos, relacionadas al software libre y al movimiento que lleva su nombre.
Este año, en El Salvador, la sede del FLISOL sera en:

Universidad Evangélica de El Salvador

Fecha: Sábado 25 de abril del 2009
Detalles de la organización: Infórmese aquí
Además en el sitio web de FLISOL El Salvador y en su Wiki

Adicionalmente, en Kradssen nos comparte estas imágenes para usar en nuestro blog. Y cabe mencionar, que la organizadora del evento, en esta ocasión, es nada más y nada menos que la querida "Gabys", pueden visitar su blog dando clic aquí.

¡No dejen de asistir! Habrán charlas muy interesantes, a las que SI vale la pena ir. Espero que nos podamos ver en el FLISOL, saludos!

FLISOL 2009

El Festival Latinoamericano de Instalación de Software Libre (FLISOL), es un evento organizado por comunidades de usuarios de Software Libre, para promover y difundir el uso de estas tecnologías. El FLISOL es un evento que se realiza de manera simultanea desde el año 2005 en todas las ciudades de latinoamerica que deseen participar. En el año 2008, de acuerdo a la wikipedia: "participaron más de 200 ciudades en 18 países de Latinoamérica."

El objetivo de este evento, es presentar el software libre de la mano de su representante más conocido: GNU/Linux, en sus distribuciones más populares como lo son Debian, Ubuntu, ArchLinux, Mandriva, OpenSuse, Fedora, Gentoo, Slackware, etc...
Y claro que no queda descartada la instalación de otras aplicaciones libres como lo son: OpenOffice.org, The Gimp, Pidgin, Blender, Eclipse, etc... y otros sistemas operativos libres: OpenSolaris, FreeBSD, OpenBSD, GNU/HURD, etc...

Durante el FLISOL, se imparten charlas, ponencias y talleres, sobre temas locales, nacionales y latinoamericanos, relacionadas al software libre y al movimiento que lleva su nombre.
Este año, en El Salvador, la sede del FLISOL sera en:

Universidad Evangélica de El Salvador

Fecha: Sábado 25 de abril del 2009
Detalles de la organización: Infórmese aquí
Además en el sitio web de FLISOL El Salvador y en su Wiki

Adicionalmente, en Kradssen nos comparte estas imágenes para usar en nuestro blog. Y cabe mencionar, que la organizadora del evento, en esta ocasión, es nada más y nada menos que la querida "Gabys", pueden visitar su blog dando clic aquí.

¡No dejen de asistir! Habrán charlas muy interesantes, a las que SI vale la pena ir. Espero que nos podamos ver en el FLISOL, saludos!

Skype para Ubuntu de 64bits

Hace un par de semanas, finalmente me canse de estar usando Windows en la laptop del trabajo, así que decidí sacar de su miseria a la pobre maquina, ser infiel al sistema operativo de los gamers y ponerle "otra cosa".
La "afortunada" es una Compaq CQ45:

"No es una maravilla, pero es una buena maquina."

Mi única duda, era si ponerle Debian o Ubuntu de 64bits... recordé las palabras de un blogger Hondureño: "Debian es para Desktops, y Ubuntu es para Laptops." Sinceramente, para mi son lo mismo, pero tenia el disco de Ubuntu a la mano. Para no aburrirlos la laptop ya tiene Ubuntu. Y antes de que se haga un flamewar sobre que distro es mejor, dejen me compartir una idea que siempre he tenido bien clara:

"Sinceramente, tener una u otra distro NO IMPORTA, lo que importa es que la maquina tenga UN SISTEMA OPERATIVO DE VERDAD (LINUX, HURD, OPENSOLARIS, BSD) y que este sistema sea LIBRE".

¿Sabían que el disco de Ubuntu de 64bits no tiene modo "live CD"? usa la instalación en modo texto, lo que para mi es fenomenal - personalmente prefiero ese tipo de instalaciones - pero hay que aceptarlo, no es muy "User Friendly".

Uno de los percances que tuve con respecto a esta migración (de 32 bits a 64 bits) fue con un programa muy útil que estoy usando mucho últimamente: Skype.
Como no me pagan para hacer publicidad sobre Skype, lo mejor que puedo hacer es dejar que la Wikipedia lo explique, y dejar un vinculo a su pagina web.

Mi problema es que Skype sólo está disponible en paquetes para arquitectura 32 bits, yo demando que mis programas usen por completo la potencia de mis procesadores.
Si alguien más se encontró con este problema, lo mejor que puede hacer es seguir esta sencilla guía para instalar Skype de 32 bits, en Ubuntu de 64 bits:

1. Necesitaremos descargar versiones de 32 bits de algunas librerías para que Skype no nos de ningún error al momento de iniciar. Todo se resume a ejecutar este comando:

sudo apt-get install ia32-libs ia32-libs-gtk ia32-libs-sdl lib32asound2

2. Ahora de clic a este vinculo y descarguen el paquete: http://www.skype.com/go/getskype-linux-ubuntu-amd64. Ojo, este NO es un paquete de 64bits, es solo un paquete que tiene las dependencias correctas para Ubuntu 8.04 o mayor (de 64bits).

3. Bien, si falta alguna dependencia, pues hay que resolverla, y despues de eso, solo nos falta Skype. Debido a la variedad de Hardware y servidores de audio, la tarea de configuración de audio y video, queda a discreción del lector, me exonero de "ese asunto".

"Ahora ya tienes listo tu Skype :)"

Bien, espero que esta pequeñisima guía le ayude a algun internauta por ahi, a instalar esta util aplicacion. Cabe mencionar que tambien existen aplicaciones 100% libres, que tiene casi la misma utilidad que Skype, como son: Ekiga (antes conocido como GnomeMeeting), despues hablaremos un poco del porque usar Software Libre, en vez de Freeware.

Saludos!

Skype para Ubuntu de 64bits

Hace un par de semanas, finalmente me canse de estar usando Windows en la laptop del trabajo, así que decidí sacar de su miseria a la pobre maquina, ser infiel al sistema operativo de los gamers y ponerle "otra cosa".
La "afortunada" es una Compaq CQ45:

"No es una maravilla, pero es una buena maquina."

Mi única duda, era si ponerle Debian o Ubuntu de 64bits... recordé las palabras de un blogger Hondureño: "Debian es para Desktops, y Ubuntu es para Laptops." Sinceramente, para mi son lo mismo, pero tenia el disco de Ubuntu a la mano. Para no aburrirlos la laptop ya tiene Ubuntu. Y antes de que se haga un flamewar sobre que distro es mejor, dejen me compartir una idea que siempre he tenido bien clara:

"Sinceramente, tener una u otra distro NO IMPORTA, lo que importa es que la maquina tenga UN SISTEMA OPERATIVO DE VERDAD (LINUX, HURD, OPENSOLARIS, BSD) y que este sistema sea LIBRE".

¿Sabían que el disco de Ubuntu de 64bits no tiene modo "live CD"? usa la instalación en modo texto, lo que para mi es fenomenal - personalmente prefiero ese tipo de instalaciones - pero hay que aceptarlo, no es muy "User Friendly".

Uno de los percances que tuve con respecto a esta migración (de 32 bits a 64 bits) fue con un programa muy útil que estoy usando mucho últimamente: Skype.
Como no me pagan para hacer publicidad sobre Skype, lo mejor que puedo hacer es dejar que la Wikipedia lo explique, y dejar un vinculo a su pagina web.

Mi problema es que Skype sólo está disponible en paquetes para arquitectura 32 bits, yo demando que mis programas usen por completo la potencia de mis procesadores.
Si alguien más se encontró con este problema, lo mejor que puede hacer es seguir esta sencilla guía para instalar Skype de 32 bits, en Ubuntu de 64 bits:

1. Necesitaremos descargar versiones de 32 bits de algunas librerías para que Skype no nos de ningún error al momento de iniciar. Todo se resume a ejecutar este comando:

sudo apt-get install ia32-libs ia32-libs-gtk ia32-libs-sdl lib32asound2

2. Ahora de clic a este vinculo y descarguen el paquete: http://www.skype.com/go/getskype-linux-ubuntu-amd64. Ojo, este NO es un paquete de 64bits, es solo un paquete que tiene las dependencias correctas para Ubuntu 8.04 o mayor (de 64bits).

3. Bien, si falta alguna dependencia, pues hay que resolverla, y despues de eso, solo nos falta Skype. Debido a la variedad de Hardware y servidores de audio, la tarea de configuración de audio y video, queda a discreción del lector, me exonero de "ese asunto".

"Ahora ya tienes listo tu Skype :)"

Bien, espero que esta pequeñisima guía le ayude a algun internauta por ahi, a instalar esta util aplicacion. Cabe mencionar que tambien existen aplicaciones 100% libres, que tiene casi la misma utilidad que Skype, como son: Ekiga (antes conocido como GnomeMeeting), despues hablaremos un poco del porque usar Software Libre, en vez de Freeware.

Saludos!