Y ahora sí, lo más jugoso de este pequeño tutorial.

4. Creamos nuestro proyecto

Creamos un directorio que contenga todos los archivos relacionados con el proyecto. Por ejemplo, dentro del HOME de nuestro usuario creamos la carpeta HolaMundo.

~$ mkdir HolaMundo

Ingresamos a la carpeta recién creada usando el comando cd.

~$ cd HolaMundo/

Creamos el archivo de nuestro programa “Hola Mundo“. Podemos utilizar el editor de texto que más nos guste. Ahora para simplificar las cosas simplemente lo que vamos a hacer es ejecutar el siguiente comando:

~/HolaMundo$ echo "print(\"Hola Mundo\")" > holamundo.py

De esta manera simplemente nos crea el archivo holamundo.py dentro de la carpeta HolaMundo con la instrucción que imprimirá el saludo.

Podemos probar nuestro flamante nuevo programa con la siguiente instrucción:

~/HolaMundo$ python holamundo.py
Hola Mundo
~/HolaMundo$

Así hemos creado nuestra primera versión del programa. Ahora es cuestión de iniciar Git para que controle nuestras versiones futuras.

5. Iniciamos Git

Para comenzar a utilizar Git podemos configurar algunas de las opciones generales, en el libro en la sección 1.5 se detallan algunas de estas opciones. En este caso quiero mostrarles cómo se debe hacer para configurar sólo las opciones para el repositorio local.

~/HolaMundo$ git config --local user.name lecovi
~/HolaMundo$ git config --local user.email colomboleandro@bitson.com.ar
~/HolaMundo$ git config --local core.editor vim

Con estas opciones le estoy definiendo que mi nombre de usuario para este proyecto es “lecovi“, que mi mail para este proyecto es “colomboleandro@bitson.com.ar” y que el editor por defecto que quiero usar cuando ejecute commit es el vim.

Para tener Git en nuestro sistema tenemos que tener instalado el paquete git.

La ventaja que tiene usar Git es que corre localmente en el direcotorio de trabajo de nuestro proyecto. Por eso tenemos que inicializarlo en el direcotorio del proyecto con el comando init.

~/HolaMundo$ git init
Initialized empty Git repository in /home/leo/HolaMundo/.git/
~/HolaMundo$

Ahora vamos a crear el archivo .gitignore que le dirá a Git qué archivos y directorios no tiene que seguir. Para mayor información podés consultar el libro. En este caso vamos a decirle que ignore el mismo archivo .gitignore y todos los archivos terminados con .pyc.

~/HolaMundo$ echo .gitignore >> .gitignore
~/HolaMundo$ echo *.pyc >> .gitignore

6. Agregando archivos

Ahora tenemos que agregar los archivos (en este caso sólo tenemos un archivo el holamundo.py, pero creo que se entiende la idea, ¿no?). Utilizando el comando add le diremos que agregue todo el contenido del directorio (exceptuando lo que hayamos escrito en el archivo .gitignore).

~/HolaMundo$ git add .
Es importante destacar que acá hemos utilizado . (punto) para decirle que agregue todo el contenido, podríamos haber hecho una lista separada por espacios de los archivos y directorios que queremos agregar. O ejecutar sucesivas veces el comando git add.

7. Creando nuestra versión

Una vez que hemos configurado Git y agregado todos los archivos que queríamos tener controlados por nuestro sistema de control de versiones tenemos que hacer el famoso commit.

Con esta instrucción estaremos estableciendo un punto en nuestra historia de desarrollo. Para el primer caso es usual hacer un commit con la descripción “Initial commit“. Por lo general yo omito el estado staged y simplemente ejecuto el comando commit con la opción -a.

~/HolaMundo$ git commit -a

Esto nos abrirá el editor que tengamos seteado por defecto, en mi caso vim, y podremos escribir el detalle del commit. En este caso, simplemente voy a escribir lo mencionado anteriormente. Una vez que guardemos el archivo con el editor, Git se ocupará de hacer el commit.

8. Agregando un repositorio remoto

Ahora es momento de decirle a nuestro Git local que tiene un repositorio remoto. En el libro tenemos descrito el procedimiento para realizar la creación del repositorio en GitHub. En esta sección vamos a utilizar lo que dejamos pendiente en la sección 3 del post anterior.

Para agregar el repositorio remoto tenemos que usar el comando git remote add donde se le pasa como argumento un nombre o alias al repositorio y la URL del mismo. En este caso vamos a usar la del proyecto que cree en Google Code.

Ustedes por supuesto pueden crear sus propios proyectos y utlizarlos de la misma manera.
~/HolaMundo$ git remote add gc https://code.google.com/p/lecovi-hello-world/

Ahora finalmente para subir nuestro repositorio local al remoto ejecutamos el comando push.

~/HolaMundo$ git push gc master

Como en la sección 3 habíamos creado el archivo .netrc utilizará los parámetros que están almacenados en ese archivo para conectarse con el servidor. Y subirá la rama master al repositorio que guardamos como gc.

En la página de nuestro proyecto de Google Code, podemos ver en la sección Source en el apartado Browse el contenido de nuestro proyecto.

Próximamente…

Hasta acá hemos completado el tutorial de cómo arrancar un proyecto con Git y Google Code.

En la próxima y última entrega de este mini-tutorial estaremos revisando cómo hacer cambios en nuestro proyecto y que se vean reflejados en nuestro sistema de control de versiones.

Saludos!

Anteriormente ya había sido publicado como obtener el efecto exposé en otros distros por Brizno. En este artículo veremos como hacerlo en Gentoo.

Para los que no sepan que es el efecto exposé se ve así:

Así como en Gnome al ir a actividades, básicamente muestra todas las aplicaciones abiertas ordenándolas en la pantalla, y permite seleccionar cualquiera entre las que nos muestra.

Enlaces sobre otras distros:

Arch Linux

Debian y derivados

Overlays

Vamos a usar Overlays, así que si no lo tienen instalemos layman, el cual les puede tomar un rato u horas, sobre todo por compilar git:

USE="git subversion" sudo emerge -a layman

Es deseable que añadan git subversion ya incluido arriba, además no olviden que hay otros USEs disponibles, sobre todo son USEs de lo que está basado el Overlay, por si lo necesitan y no vuelvan a recompilar a layman.

- - bazaar : Support dev-vcs/bzr based overlays

- - cvs : Support dev-vcs/cvs based overlays

- - darcs : Support dev-vcs/darcs based overlays

+ + git : Support dev-vcs/git based overlays

- - mercurial : Support dev-vcs/mercurial based overlays

Añadiendo el Overlay

No olviden indicarle a make.conf que usan overlays si nunca lo han hecho:

echo "source /var/lib/layman/make.conf" >> /etc/portage/make.conf

Si es la primera vez que van a usar layman deben continuar con lo siguiente, añadir otro Overlay, o bien crear ustedes mismos el archivo en blanco /var/lib/layman/make.conf, de lo contrario portage se quejará

Ahora ejecuten el siguiente comando para añadir el overlay swegener, que es el que contiene el ebuild.

layman -a swegener

Ajustando el ebuild

La url de ebuild para descargar el código fuente en el momento de escribir este artículo no está disponible, así que hay que editar el ebuild manualmente:

sudo nano /var/lib/layman/swegener/gnome-extra/brightside/brightside-1.4.0.ebuild

En la linea con SRC_URI=, remplazen la URL por esto:

http://pkgs.fedoraproject.org/repo/pkgs/brightside/brightside-1.4.0.tar.bz2/df6dfe0ffbf110036fa1a5549b21e9c3/brightside-1.4.0.tar.bz2

Seguido vamos a general el nuevo hash:

sudo ebuild /var/lib/layman/swegener/gnome-extra/brightside/brightside-1.4.0.ebuild digest

Instalar Brighside

sudo emerge -a gnome-extra/brightside

Compilar Skippy-XD

Instalen mercurial, el cual también les puede tomar un rato, y nos permitira bajar el directorio para la compilación:

sudo emerge -a mercurial

Esto descargará skippy para compilarlo:

hg clone https://code.google.com/p/skippy-xd/

Procedemos a compilar:

cd ~/skippy-xd

make

sudo make install

Configurando

Añadan brightside a sus programas de login, por ejemplo en openbox ~/.config/openbox/autostart deben añadir:

brightside &

Ejecuten:

brightside-properties

Y aparecerá la ventana de configuración Screen Actions, marcamos el círculo de “Configurable Actions” y marcamos la casilla de la esquina de la pantalla que queramos activar, en este ejemplo será la inferior izquierda (Bottom left corner) y en su menú desplegable elegiremos “Custom action…” y aparecerá otra ventana como en la siguiente imagen:

Brightside

Cerramos y ejecutamos brightside:

Modificar el tiempo de respuesta (Opcional)

Les recomiendo que editen la velocidad si les parece lento el tiempo de respuesta , por supuesto que si ya se les hace perfecto como sirve pueden omitir este paso.

En el área de notificación deben tener un icono nuevo, denle click secundario, ahora clicken en Preferences

En la barra señalada ajusten la velocidad como deseen, también pueden ejecutar directamente:

brightside-properties

Listo, ya tienen el efecto exposé en su Gentoo.

 

Categorías: Noticias

Una noticia en phoronix comenta que continua el debate en Debian sobre que hacer con su sistema de inicialización. Ya desde hace tiempo hay voces que piden la renovación y que se deshagan del vetusto sysvinit. Y dentro de esas voces la rivalidad entre quienes apoyan a systemd, quienes apoyan a upstart y (muy pero muy pocos) quienes apoyan a openrc………..y no están con ganas de soportar a más de uno.

La discusión es feroz y es como para armar un libro de varios tomos (van por los 2500 mensajes, y este bug se abrió hace sólo 2 meses!!!). systemd cuenta con el apoyo de varias distros que migraron exitosamente (Fedora, Arch, OpenSuse, etc.), pero sus seguidores lamentan que Debian tenga que mantener versiones para el kernel de FreeBSD, en donde systemd no está portado (ni Lennart piensa portarlo). Lo que sí está portado a FreeBSD es OpenRC (en verdad se logro portar a Debian KFreeBSD), pero sólo Gentoo y sus derivadas lo usan (excepto Sabayon que usa systemd). Y Upstart, tiene la ventaja de venir del downstream (Ubuntu y sus derivadas y también Chrome OS), pero queda corto en comparación con systemd. Y si a esto le sumaramos la discusión fuera de las listas de Debian, entre las que está la opinión de Lennart y Patrick Lauer respondiéndole (a Lennart), cualquier flamewar queda chico en comparación.

Igual fue noticia en phoronix que ya hay opiniones dentro del comité técnico de Debian. Por un lado está Ian Jackson (mantenedor de demonios de Debian) quien está a favor de Upstart. Lo considera por su minimalismo, por integrarse mejor en el código de un demonio, por su facilidad para empaquetarse, tener una comunidad menos arrogante (según él) y por estar más listo para ser elegido para Jessie (OpenRC no lo está aún). También indica que las desventajas como la falta de activación de sockets IPv6 y UDP o la activación múltiple de sockets no requieren decisiones estructurales difíciles y por lo tanto pueden resolverse más fácilmente.

Y por otro lado está Russ Allbery quién está a favor de systemd: Primero opina que OpenRC es la alternativa más conservadora y que ni siquiera se quiere molestar en resolver bugs como la falta de integración con eventos a nivel del kernel o su dependencia más en los scripts de shell que en la sintaxis declarativa. En cuanto a manejo de servicios, destaca la activación de sockets (no sólo inicializarlos sino que lo hagan en paralelo), la integración del status del demonio (más completo que en upstart) y la seguridad en profundidad. También recuerda que ya Debian utiliza systemd (sobretodo logind) para ciertas aplicaciones como udev y gnome (cuya versión 3.8 ya está en testing) y que tiene ya pensado el plan de migración.

Y en cuanto a la cuestion de la portabilidad, los fans de systemd en LWN.net dicen “No existe el software portable, sólo existe el software que fue portado.” O sea, o los portadores de Debian para kFreeBSD y Hurd lo hacen funcionar, o se van a cagar. Y esta segunda opción pesa fuerte ya que (según el popcon) sólo el 0,09% de los usuarios de Debian tienen instalado el Kernel de FreeBSD.

Mientras tanto, el desarrollador de KWin, Martin Gräßlin anda siguiendo la discusión en Debian que les había comentado, y le encanta la comparación que hizo Russ Allbery entre systemd y upstart y comenta en su cuenta de google+ que tiene intención de integrar systemd al Plasma, y de paso que cualquier entorno que use Wayland se pase a systemd. En especial quiere utilizar la activación de sockets para iniciar la sesión de KWin.

Christian Loosli le pide que KDE no tenga una alta dependencia. Martin le responde que KDE tiene una alta dependencia sobretodo de QT, pero fuera de joda, sólo lo quieren por características que no están ni en OpenRC ni en Upstart, pero lo más importante, porque quieren que KDE dependa de kdbus (su propio explorador de servicios d-bus un proyecto que busca integrar d-bus al kernel) el cual ya depende de systemd. También dice que no se preocupe por el sistema de inicialización porque esto va a ser independiente de si usas OpenRC o SysVInit (de hecho, Gentoo usa systemd a pesar de que su init sea OpenRC. Por lo tanto “no debería haber problema con Debian”). Luego es Eric Hameleers (miembro del coreteam de Slackware) quien se queja de que se quiera elegir por tecnologías que sólo son para Linux (otra vez el tema de la portabilidad). Martin le pide que lea el post de los mitos falsos que Lennart escribió. Que a Martin le tiene confianza.

¿Que opinan del panorama? La próxima noticia que tenga que hacer un artículo sobre systemd, lo voy a hacer como un relato de partido de futbol.

Yakuake, es un emulador de terminal al más puro estilo Quake, o sea, una terminal desplegable.

Ya Wolf nos explicó cómo instalar y configurar Yakuake en KDE hace un tiempo, hizo un brillante artículo por lo que no hay necesidad de volver a repetir lo ya explicado:

Instalar y configurar Yakuake en KDE

Por defecto se vería similar a esto:

Como pueden apreciar, no se nos muestra en pantalla completa o full screen, o sea, el panel superior (donde está la hora, etc) lo podemos ver, así como también el dock (Plank) impide que Yakuake ocupe el 100% de la pantalla.

O sea, yo deseo que se muestre siempre así:

Como pueden ver, ocupa el 100% de mi pantalla, no veo nada más excepto la terminal.

Para que Yakuake se muestre así, aquí les dejo los pasos:

1. Ejecutar Yakuake

2. En las opciones de configuración, en la misma primera pestaña (Ventana) debemos subirle al 100% la Anchura y la Altura como muestro en la imagen:

3. Presionamos Ctrl + F3 y nos aparecerá en la esquina superior izquierda un pequeño menú con opciones de la ventana, deben ir a: Más acciones -» Preferencias especiales de la ventana:

4. Ahí podremos ver la opción Pantalla Completa, donde debemos habilitarla, seleccionar Aplicar Inicialmente y marcar Si . Les muestro cómo les debe quedar en la imagen:

 

5. Listo!

Esto bastará para que cada vez que desplieguen Yakuake, siempre se les muestre al 100%, en Pantalla Completa.

Bueno hasta aquí el artículo, como pueden apreciar… esta opción no es única o exclusiva de Yakuake, pueden configurar así o con opciones similares cualquier aplicación de KDE, y mucho más (quitarle el título, etc) … KWin es sin dudas maravilloso.

Saludos

Como lo prometido es deuda, acá vamos a seguir los pasos necesarios para crear un proyecto en Google Code.

1. Nos logueamos en Google

La primera cosa que tenemos que hacer es ingresar a nuestra cuenta de Google, ingresamos al sitio de Google Code y en la esquina superior derecha vamos a encontrar el acceso al login. A la izquierda podemos cambiar el idioma.

2. Creamos el Proyecto

Una vez logueados en el sitio con nuestra cuenta, esto lo podemos verificar porque en la esquina superior derecha veremos nuestra dirección de correo electrónico de Google, y podemos hacer click sobre el vínculo que dice Create a new project. Esto nos redigirá a una página para completar los datos de nuestro proyecto.

Completamos los datos de nuestro proyecto y una vez que terminamos simplemente vamos a darle al botón de Create Project.

Ahora que tenemos creado nuestro proyecto nos muestra la página principal del mismo. Por ahora no haremos mucho más con Google Code. Sólo nos resta sacar la información para poder conectarnos después remotamente y subir los archivos a través de Git.

3. Obteniendo los datos del repositorio en Google Code

Para eso tenemos que ir a la sección de Source (código fuente) y ahí nos brindará 2 opciones para conectarnos. 

La Opción 1 nos pedirá el password de googlecode.com cada vez que querramos hacer algún push, algo que resulta eventualmente bastante tedioso. Sobre todo porque esta password es una que se generó automáticamente con el proyecto, no es nuestra password de nuestra cuenta. Por eso recomiendo utilizar la Opción 2.

Utilizaremos la Opción 2, hacemos click en el vínculo que dice googlecode.com password. Esto nos mostrará una nueva página y de ahí copiaremos la última línea de la primera sección. La que vemos resaltada en la siguiente imagen.

No se preocupen, esta password que ven ya la regeneré y no sirve para más nada 😉

Creamos un archivo en el HOME de nuestro usuario que se llame .netrc y adentro colocamos el contenido que copiamos recién de la página. En este caso:

machine code.google.com login colomboleandro@bitson.com.ar password ZG2UP8dW5pV7

Próximamente…

Hasta aquí hemos creado el proyecto en Google Code y ya tenemos listo el archivo que nos “conectará” con nuestro repositorio remoto una vez que armemos nuestro repositorio local de Git.

En la próxima parte veremos cómo crear el proyecto en nuestra máquina y configuraremos Git para el control de versiones.

Saludos!

Se acabó el tiempo para participar de nuestra competencia del mes. Realmente fue muy difícil decidir porque nos han enviado excelentes capturas de sus escritorios.

No obstante, luego de un largo rato, por fin pude elegir los que para mí son los 10 mejores escritorios. Hay un variadito muy interesante de distros, entornos, íconos, etc. ¡Para aprender, imitar y disfrutar! ¿Estará el tuyo en la lista?

1. Julián Caamaño Valverde

Distro: Debian
Conky
Wallpaper

2. Ugo Yak

Distro: Manjaro
Tema GTK: SimpleX
Dock: AWN
Íconos: Elementary (XFCE)
Wallpaper
Conky: retoque del que trae Manjaro
Mouse: PolarCursor Blue

3. José Luis Viéitez

Distro: Debian Testing (jessie)
Entorno Escritorio: Gnome Shell
Gnome-Theme: Dark Shine
Iconos: AWoken
Utilidades extras: gtk, metacity, conky, gnome-extensions

4. Adolfo Rojas G

Distro: ArchLinux
Entorno Cinnamon: Tema de apariencia a gnome shell (disponible en conf. cinnamon) e Icono de inicio, imagen archlinux
Conky Gold & Grey (cpu, disk,mem,net,time)
Fondo de escritorio: Battlefield 4

5. Enrique Valdez Jordan

Distribucion: Linux Mint 15
Entorno de escritorio: KDE 4.11.2
Estilo de elementos graficos: Oxygen Transparent
Tema Plasma: H2O
Plasmoide: USU notifications, media controls
Iconos: Oxymentary
Iconos bandeja de sistema: Helium
Lanzador: Lancelot
Dock: Cairo Dock modificado
Fondos de Escritorio

6. Francisco Javier Guzmán

Distro: Linux Mint xface
Iconos: Plateu // Wallpaper
Conky: Colors modificado
Conky

7. Victor Alexander Pohl

Linux mint 15
Entorno: cinnamon
Tema: Tyr jord
Iconos: Compass
Conky: Gotham modificado
Cooverglobus: eOS modificado
y Docky

8. Ben Molina

Distro: ArchLinux (en realidad es ArchBang xD)
Entorno de escritorio / Administrador de ventanas: Awesome WM
Tema de iconos: AwOken
Tema GTK: Modern Flat Dark

9. Ivoje Neotreut

Openbox
GTK: Numix (Esta modificado, el tema es totalmente negro con azul claro para las selecciones, en lugar del naranja)
Iconos: Moka, aunque lucen muy poco, solo se ven en Thunar (Las carpetas)
Conky
TInt2

10. Adolfo Rojas G

Distro: Ubuntu 13.04 Raring Ringtail
Gestor de ventanas Unity (Modificado)
Tema de cursor: DasBlack
Tema GTK: Delorean-Dark.theme-3.8
Cairo-Dock 2D con 3 Docks (uno está oculto) con íconos modificados.
Conky LSD
Fondo de escritorio: EVE

Yapa: Kostan Rey

El que más votos positivos obtuvo este mes… ¡por lejos (75 en total)!
¡Feliz 2014!