La imagen del día: Bill recomienda Ubuntu.

Navegando por ahí, encontre en un foro una firma muy curiosa que me llamo mucho la atención además me parecio muy graciosa.

El mismisimo Bill promocionando Ubuntu que cosa más chuzca. Nunca la había visto aunque no se si ya tiene tiempo, aun así me parece muy graciosa.

Teclado para Ubuntu de Zareason

Leo en el blog de markdbd que Zareason sacó al mercado un teclado especialmente diseñado para Ubuntu, si no lo sabiamos Zareason se especializa en Hardware Linux. El caso es que esta bastante feo, al menos a mi no me gustó, ni el precio($ 25) ni el diseño.

Aquí dejo unas caps:

El GreenPC(GooglePC) todo un exíto

Hace tiempo hablamos del Google PC, y de que incluía el gOS como sistema operativo además de que esta basado en Ubuntu Linux tiene añadidos los principales servicios de Google como son: YouTube, Gmail, Blogger, Google Maps, Picasa, etc. Además de incluir otras aplicaciones como Skype y OpenOffice ó Wikipedia.

Pues atraves de google.dirson.com me entero que no es Google PC sino GreenPC y el green le viene de consumir pocos recursos. Tambien deciamos que Wal-Mart estaba vendiendo estos equipos de Everex en sólo USD $200, pues resulta que los 10,000 equipos que se pusieron a la venta en todo el país(USA) ya se han agotado y que el producto ha sido todo un exito, incluso ya estan en espera de otro pedido.

En el blog de Matt Cutts se pueden ver algunas imagenes de lo que es este producto, que incluye un lector de DVD’s, bocinas USB, teclado, Mouse, entrada y salidas de audio, y demás necesidades básicas que debe tener un PC moderno.

Aqui pongo algunas de las imagenes:

En los siguientes días estaré realizando un videotutorial donde analizaremos el gOS y ver algunas ventajas y desventajas.

Por lo pronto pongo un video donde se muestra ma o meno como es su aspecto y su funcionalidad.

 

El Google PC que no es de Google

Hace algunas semanas había algunas especulaciones acerca del registro de la marca comercial Google PC por parte de un David Liu que no tiene nada que ver con Google.

Y ahora a través de Tecnorantes me entero que se lanza la dichosa Google PC como un cliente ligero, con un SO basado en Linux y Enlightenment de nombre Gos.

Mientras, Everex está vendiendo este equipo en Wal-Mart, con el gOs instalado, por 199$.Es de gama baja, pero la verdad es que no deja de ser una oferta interesante.

Entrevista al fundador de Ubuntu

Una interesante entrevista a Mark Shuttlework el hombre de 31 años que dio vida a la distribución de Linux que hoy goza de mayor popularidad.

 

No-Ubuntu un mal nombre para una causa justa

Pues si como dice el titulo, No-Ubuntu es un feo nombre para una causa que a mi parecer es justa, aunque no este de acuerdo en algunos puntos de su FAQ también concuerdo con que hay que darle un poco más de responsabilidad al usuario de lo que puede llegar a hacer en una computadora. Yo entiendo que no todos los usuarios son estudiados o es tan en vía de terminar una carrera en informática y que algunos conceptos se le pudieran complicar, pero la gran mayoría de usuarios GNU/Linux tiene algo que ver de alguna manera u otra con la informatica.

Me gusta su filosofía respecto a lo que un foro debe hacer por su comunidad, me ha tocado leer usuarios que piden ayuda ya sea con un consejo o con un minitutorial y cuando resulta que resolvieron su duda, simplemente postean “Ya lo resolví, de todas formas gracias…” y no dan a la comunidad la solución encontrada.

Quizás muchos se espanten del nombre de esta iniciativa pero como lo estoy haciendo también me gustaría que antes de poner el grito en el cielo y “arrojar mierda desde el puente” se detengan un momento a leer sus fundamentos y realmente cual es el trasfondo de su filosofía.

“NO PARA COMBATIR A UBUNTU SINO PARA MEJORAR LA MENTALIDAD (EN PRO DE LA COMUNIDAD) DE GRAN PARTE DE LOS USUARIOS DE ESTA DISTRIBUCIÓN, QUE LA MAYORÍA, CON SU FORMA DE HACER LAS COSAS, NO HACEN SINO ARRUINAR EL TRABAJO QUE DURANTE AÑOS SE VIENE CONTRUYENDO.”

Se trata de conciencia pero es un problema de esencia como usuarios de una computadora, pues he visto secretarías esperar hasta media hora a que Windows arranque, y su ignorancia o desinterés en el tema, tanto de ellas como de su departamento de sistemas, si supieran que existe un SO más eficiente en equipos de poco recursos que Windows e hicieran todo lo que este a su disposición para cambiar su rendimiento laboral. Tal ves hicieran algo o tal ves no lo harían porque su problema es no de conciencia si no de esencia como usuario de una computadora.

Y son este tipo de problemas los que hay que atacar, y creo que esta iniciativa es realmente interesante, en mi opinión me gustaría que se hiciera lo más positivo posible aunque esto siempre es el camino más largo y cansado. Pensar en el “NO-UBUNTU” me parece algo como el “NO-WINDOWS” de la comunidad linuxera y debería ser cambiado por algo menos agresivo y más ilustrativo de lo que realmente es: “”usar Ubuntu con tus propias reglas pero sabiendo perfectamente que y como lo estas haciendo”, pero es sólo un nombre para un proyecto y lo que realmente le puede dar prestigio es las acciones de aquellos que se aventuren a formar parte de el.

Por cierto ahora mismo estoy en mi Ubuntu Edgy y mi querido Beryl con tan sólo 256 Mb de RAM DDR y una Tarjeta ATI Radeon 9200 y me funciona 3 veces más rápido que mi otro SO…Windows XP UnAttended Edition v7 según esto muy optimizado.

Mi experiencia Ubuntu+Beryl + Java

Bueno, en este “break” que me he dado debido a la desaparición de certificate.educaleft.com he estado intentando algo que hace tiempo desisti por que simplemente no funcionaba: instalar Beryl en mi Ubuntu. Mi experiencia había sido muy grata hasta que probe instalar NetBeans 5.5 y no funcionó. La razon…muy simple: Beryl.

Estuve leyendo algunos blogs que daban ciertas posibles soluciones, sin embargo la única que me ha funcionado es la siguiente:

Primero debemos abrir una terminal y entrar como root y después abrir el siguiente archivo con este comando:

sudo gedit /etc/environment

Una vez abierto, colocamos esta línea al final:

AWT_TOOLKIT=”MToolkit”

Lo guardamos y al reiniciar ya debería funcionar el NetBeans. De no ser así tendremos que cambiar de gestor de escritorio a metacity y después volver a cambiar a Beryl.

Linux + Beryl + Virtualizacion

Bueno hace pocos dias veia en Ubuntu Facil un video en donde se virtualizaban todos los windows 9x, 2k hasta XP usando Linux From Scratch y QEmu 0.9 con KVM, en un equipo con procesador core duo y 512 Mb de Ram.

 

Simplemente magnifico.

Buen Dia.

Tips para programar en Linux

Si hemos programado en Windows pero estamos interesados en la programación en Linux, estos consejos resultan especialmente útiles para cambiar algunas de las ideas y minimizar el choque ocasionado por el cambio de cultura cuando encontramos diferentes ideas y formas de pensar.

EVALUAR CADA ALTERNATIVA DISPONIBLE

A diferencia de la Interfaz de Programación de Aplicaciones (API) unificada en Windows que provee a los programadores con un único método para alcanzar un cierto objetivo, Linux provee diversas formas de alcanzar el mismo objetivo. Por ejemplo hay una variedad de cajas de herramientas (toolkits) de abstracción de la Interfaz Gráfica de Usuario (GUI), siendo las más importantes QT y GTK para escribir programas de Interfaz Gráfica de Usuario. Además, no se necesita elegir entre C o C++. Hay muchas opciones para programar, incluyendo la escritura de una serie de comandos en un archivo de texto para el intérprete de comandos (shell scripting), Perl, Python, Gambas, Java, Mono(Plataforma .NET) y PHP. Así que no siempre hay que tener una idea fija de que se necesita aprender del modo “difícil”.

No hay que abrumarse con las opciones. Sólo hay que ser consciente de ellas y tomar aquellas herramientas y técnicas con las que nos sintamos mejor.

LOS IDEs NO SON NECESARIAMENTE MÁS PRODUCTIVOS

Los programadores que han utilizado extensamente el Visual Studio de Microsoft para realizar sus desarrollos posiblemente se sientan incómodos al adaptarse a la manera en que se hacen las cosas en Linux. Aunque hay algunos Entornos Integrados de Desarrollo (IDEs, por sus siglas en inglés) bastante decentes en Linux, incluyendo a Kdevelop, Anjuta y Eclipse, pudiéramos encontrar que utilizando un editor de texto y creando un archivo de descripción (make file, en inglés) sea una mejor idea a largo plazo.

Cuando desarrollamos aplicaciones de Software Libre, posiblemente no queramos atar el desarrollo a una plataforma o a un Entorno Integrado de Desarrollo específicos, teniendo en cuenta que nuestro código será compartido y que otros programadores pudieran contribuir en el proyecto. A pesar de que los Entornos Integrados de Desarrollo no son una mala idea, posiblemente encontremos que al desarrollar proyectos más pequeños utilizando un editor de texto simple y un archivo de descripción sea una mejor idea.

NO BUSCAR CARACTERÍSTICAS ESPECÍFICAS DE UNA DISTRIBUCIÓN

Pudiera sorprender a muchos programadores de Windows saber que prácticamente se puede no hacer supuestos de la configuración por defecto de Linux en la máquina del usuario final. Diferentes distribuciones usan diferentes ubicaciones de archivos de configuración y ajustes. A menos de que estemos escribiendo una utilidad de configuración del sistema para una distribución en particular, no hay que hacer supuestos específicos de una distribución. De igual modo nunca hay que forzar a los usuarios a que trabajen como un administrador, a menos de que el propósito exclusivo de la aplicación sea el de modificar ajustes específicos del sistema.

NO MODIFICAR NI TRATAR DE MODIFICAR ARCHIVOS DEL SISTEMA.

Además de no ser una buena práctica de programación, no se puede asumir que determinado archivo de sistema existe en la máquina del usuario final (debido a diferencias específicas de la distribución).

Tampoco podemos modificar archivos de sistema como un usuario “normal” (sin los privilegios necesarios) y no se supone que una aplicación normal de productividad sea ejecutada como administrador.

En la mayoría de los casos, encontraremos que apenas tenemos alguna razón buena para tocar archivos específicos.

SER VISUALMENTE CONSISTENTE

Los programadores de la Interfaz Gráfica de Usuario, especialmente programadores de GTK y QT, necesitan entender que estas bibliotecas son bastante modificables (el usuario final puede modificar la apariencia visual de la Interfaz Gráfica de Usuario en casi cualquier forma posible).

Por lo tanto, hay que evitar usar fuentes (de letra) o colores específicos en nuestra Interfaz Gráfica de Usuario. No es necesario. No hay que forzar al usuario final a que instale alguna fuente (de letra) particular en su sistema. Hay que dejar el despliegue visual de la aplicación exclusivamente a la biblioteca de la Interfaz Gráfica de Usuario que utilizamos. A menos de que estemos escribiendo un procesador de palabras casi nunca requeriremos manejar fuentes (de letra) en el código de nuestra aplicación.

ESTAR PREPARADOS PARA REALIZAR ALGO DE INVESTIGACIÓN

Linux no viene con una herramienta parecida al MSDN que nos proporcione documentación para cada herramienta de programación individual o para cada Interfaz de Programación de Aplicaciones que se encuentre disponible allá fuera. Esto no es práctico debido a que Linux no es desarrollado por una sola compañía. La mayoría de las veces si estamos utilizando bibliotecas de terceros, podremos encontrar documentación (ya sea a través de una descarga o en línea) en el sitio en Internet oficial del encargado de la biblioteca. También hay que estar conscientes de que muchas bibliotecas vienen con documentación incompleta o sin ella.

Posiblemente tengamos que buscar código de muestra o hasta archivos de cabecera para aprender más acerca de una biblioteca en particular. Lo bueno es que probablemente no nos topemos con esta situación con la mayoría de las bibliotecas populares de terceros, aunque siempre es bueno estar preparados (por si acaso).

NO EMPAQUETAR DEPENDENCIAS

Cuando estamos creando paquetes que pueden ser distribuidos no hay que incluir dependencias junto con nuestra tarball (Bola de Alquitrán, paquete de archivos creados con la utilidad Unix tar). Sólo hay que incluir el código fuente y ofrecer instrucciones de compilación (entre más genéricas, mejor). También hay que mencionar las dependencias que son requeridas en los archivos LÉEME (README) o INSTALACÍON (INSTALL) y en nuestro sitio en Internet.

Ya que la mayoría de las distribuciones Linux poseen sus propios sistemas de gestión de paquetes (y si nuestra aplicación es lo suficientemente buena, posiblemente pueda ser incluida en el depósito de paquetes oficial), debemos de dejar el manejo de las dependencias al usuario final que compila nuestro programa en forma manual o al encargado del paquete de la distribución que envía nuestra aplicación como parte de su paquete. Puesto que toda distribución Linux tiene una forma distinta de administrar las dependencias, no hay que intervenir con ellas creando una rutina de instalación que intente ser inteligente e instale otras bibliotecas.

Aparte de crear problemas con las versiones, resulta tedioso y engorroso incluir dependencias con el programa. También hay que probar y mantener las dependencias al mínimo, especialmente si nuestro programa tiende a usar bibliotecas exóticas de terceros.

Fuente original