Dejando de usar Gnome y Gnome Shell

hace unos dias por mera curiosidad me dio por quitar KDE (y respaldar mis archivos de configuracion por supuesto) e instalar gnome en mi querido ArchLinux, la experiencia no fue placentera.

Viniendo de haber sido un acerrimo ex usuario de gnome, en las epocas del set de versiones 2.x, e incluso recibir de buena gana el brinco a Gnome 3, justificando su falta de configuracion con el argumento “hey asi salio KDE 4 tambien, denle tiempo para que madure” y soportando la falta general de neuvas caracteristicas y usabilidad puedo decir ahora que realmente no solo no me gusta sino que me preocupa hacia donde va Gnome3.

Me es incomodo la aproximacion de tablet que tiene Gnome Shell 3.4, para equipos portatiles y PCs (graaaaannn mayoria de equipos con Linux de escritorio) cuya interfaz se maneja con unt eclado y un raton, y no con una pantalla tactil resulta poco intuitiva y poco cuidada. Es curiosos como quieren tener esta aproximacion a dispositivos moviles y tablets pero ironicamente no hay registro de una tablet o equipo tactil que piense manejar Gnome 3, casi se siente que estan haciendo un favor que nadie pidio.

No voy a escribir mas acercad e esto, la falta de opciones de configuracion y el hecho de que se requeran esxtensiones para tener funcionalidades basicas como apagar el equipo me resultan muy incomodos, que este sea el ultimo post dedicado a gnome hasta qeu muchas de esas “pequeñas fallas de diseño” sean corregidas o pulidas en su funcionalidad.

Usando Gnome (y gnome shell)

Por curiosidad y por invitacion de un amigo cercano me decidi a probar gnome3/gnome-shell en mi ArchLinux, despues de meses de haber pasado a KDE (y estar completamente agusto con ese escritorio) me decidi a quitarlo, salirme de mi zona de comfort y ver que tan avanzado, util y bueno es este entorno de escritorio.

Al igual que Ubuntu, lo probare unos dias, tentativamente a vistas de que se quede si me gusta.

El post de instalacion y dejar a punto gnome estara en unos dias, por lo pronto a disfrutar el resto de mi domingo con mi chaval, saludos

Usando Ubuntu. Conclusiones.

Ya fueron mas de 10 días de cuando me decidí por probar la nueva versión de Ubuntu 12.04.

Han sido varias sorpresas las que me dio esta versión de Ubuntu, algunas agradables y otras no tanto, pero en definitivo este sistema operativo me dio algunas sorpresas que no esperaba. Como lo aclare en el post anterior, esto no era mas que mis ganas de probar de primera mano esta versión de Ubuntu, sin ánimos de tirarle a la distro o definir el “porque deberías estar utilizando ubuntu en este momento”, posts promocionándolo o atacándolo sobran, así que vamos a mi experiencia. Leer más »

Usando Ubuntu

 

Ubuntu fue la primer distro de Linux que realmente empeze a utilizar, hace algunos años la curiosidad por ese sistema operativo me llevo mas y mas a aprender del software libre, de GNU/Linux y al final de cuentas a enfocar mi carrera a esa especifica área.

Durante estos años seguí utilizando una u otra distro dependiendo de mi curiosidad o necesidad en el momento, en el 2009 esa curiosidad me hizo dejar a mi ubuntu 8.10 (un par de meses antes de la salida de 9.04) y probar ArchLinux, y hasta ahora ha sido el sistema de mi completa preferencia.

Estos pasados días descargue la Beta2 de Ubuntu 12.04 y me hice a la idea de probar dicha distro por algunos días. Quiero probar de primera mano Unity, que dicho sea de paso nunca me gusto pero del cual quiero ver si realmente no me gusta o si es mero estigma. Me voy a meter a utilizar ubuntu one a pesar de que ya manejo 2 servicios de sincronización de archivos a ver si realmente vale la pena. Después de acostumbrarme a pacman y a AUR voy a volver a apt-get y a su sistema de PPAs y ver que tan útiles son.

Tampoco quiero metrme al papel de super-critico-linuxero  que dicta que distro es mas mejor, nada de eso, es solo mera curiosidad de su servidor ;)

Ah, y tampoco odio a Ubuntu y/o canonical

En fin, quiero utilizar la distro a manera personal por algunos días para moldear mi muy personal juicio a cerca del rumbo que esta tomando, la aproximación hacia el usuario y la enorme apuesta que canonicato esta haciendo.

¿Que si voy a quitar ArchLinux? No, lo voy a probar en otro equipo que tengo disponible para ello (Core2Duo, 4 GB de RAM, Intel 965GMA) por que llevo meses con mi sistema ArchLinux perfectamente acomodado y me da flojera respaldar configuraciones y reinstalar todo después de probar ubuntu de nuevo (que voy con la noción que voy a probar y no quedarme ahí).

Entonces así es, vamos quitándonos algunas opiniones fundamentadas en la opinión de alguien mas y vamos viendo que tal sale este curioso ecosistema llamado Ubuntu.

Saludos

Firma de paquetes y seguridad en pacman

Hace ya algunos meses hablaba de la firma de paquetes en ArchLinux, se aclaro que esa revisión de paquetes firmados era meramente opcional, con vistas a volverse obligatoria en un futuro próximo. En el post que trate esa firma de paquetes utilizaba algunos scripts para descargar y validar las firmas gpg de los developers de ArchLinux, ese método ha cambiado ya.

En las nuevas versiones de pacman, la configuración de este (/etc/pacman.conf) maneja un modelo de revisión de firmas por repositorio, algo muy recomendable de habilitar por que asegura la confiabilidad de paquetes.

Despues de actualizar pacman, instalamos el paquete archlinux-keyring:

pacman -S archlinux-keyring

Iniciamos el servidor de llaves, esto llevara un rato:

pacman-key --init

Y ahora, en vez de usar scripts para descargar las llaves de desarrolladores, poblamos las listas de llaves así:

pacman-key --populate archlinux

Este comando nos preguntara sobre las firmas a importar, aceptamos todas:

La firma se marcará como no exportable.
¿Firmar de verdad? (s/N) s

Listo, tenemos las listas de llaves de desarrolladores, ahora a habilitar la verificación de estas en pacman.

Primero que nada debemos comentar esta línea:

# For now, off by default unless you read the above.
SigLevel = Never

Dejarla asi

# For now, off by default unless you read the above.
#SigLevel = Never

Luego habilitamos la revisión de firmas según el tipo y necesidad del repositorio:

[core]
SigLevel = PackageRequired
Include = /etc/pacman.d/mirrorlist

Todo paquete de core será revisado forzosamente, un paquete no firmado y revisado no podrá ser instalado.

[extra]
SigLevel = PackageOptional
Include = /etc/pacman.d/mirrorlist

La firma del paquete será revisada, aunque no será necesario tener una revisión local de dicha firma

[community]
SigLevel = PackageOptional
Include = /etc/pacman.d/mirrorlist

Al igual que extra, revisara la firma pero no será obligatorio que pase la revisión local

Nota: al utilizar este nivel de revisión de seguridad hará imposible para el usuario instalar paquetes localmente con pacman -U por no poder revisar la firma del paquete, esto no afecta al instalar cosas de AUR (utilizar yaourt/packer)

Pequeño error al actualizar pacman

Sucede que al actualizar se nos pide que actualizemos primero pacman a su nueva version 4.0.2-1:

:: Los siguientes paquetes deben actualizarse primero:
pacman
:: ¿Desea cancelar la operación actual
:: y actualizar estos paquetes ahora? [S/n]

Pero al hacerlo hay un error que dice:

error: error al preparar la transacción (no se pudieron satisfacer las dependencias)
:: gcc: necesita gcc-libs=4.7.0-3

Esto se resuelve de la manera mas simple, haciendo que pacman reinstale pacman:

[root@delly lucain]# pacman -S pacman

Al terminar nos dara este mensaje:

Run `pacman-key --init` to set up your pacman keyring.

Que es la forma de manejar las llaves gpg de esta nueva version de pacman, que es material para el siguiente post

¿Utilizar o no utilizar testing?

Todas las distribuciones tienen sus repositorios o sistema de pruebas en donde revisan las nuevas versiones del software de las fuentes del creador (vanilla se le dice a la versión sin cambios del autor o fuente), se prueba, se reportan bugs, se parchan (a veces) y tarde o temprano se pasan a un repositorio estable en donde todos lo puedan usar.

Casi todas las distros manejan algún sistema parecido.

  • Debian tiene testing, experimental y unstable
  • Ubuntu tiene Alpha, beta y beta2
  • Fedora maneja Rawhide
  • Mandriva maneja Cooker
  • OpenSuSe hasta donde sé, utiliza Milestone
  • ArchLinux tiene testing

 

Hablando de Arch, una distro que de por si maneja versiones muy, muy nuevas de su software maneja todavía otro nivel de pruebas que vendría siendo el nivel del campo minado: el repositorio testing, lugar done esta todo lo que no ha entrado a core, extra o community. Pero, ¿vale la pena utilizar testing?

Muchas veces queremos la versión más nueva de algo (a veces sin siquiera necesitar realmente las nuevas características, si es que las hay) y no podemos esperar al periodo obligatorio de pruebas y empaquetado y recurrimos a testing, el problema es que muchos no toman en cuenta que ahí hay versiones de pruebas y posiblemente con bugs de drivers, compiladores, librerías, y cientos de dependencias que dejaran al sistema inestable y no solo la nueva versión de un navegador o entorno de escritorio.

 

Bajo esta idea la respuesta corta seria: No, no hay que utilizar testing. Pero si la curiosidad es más fuerte que la estabilidad del sistema pueden probarlo, tomando precauciones con piezas clave del sistema y deshabilitando cualquier actualización de drivers, librerías o hasta el mismo kernel para probar con seguridad la nueva versión de ese software del que no puedes esperar unos días a que pase a estable ;)

Un sistema roto con testing puede ser devuelto a su estado estable,  pero no siempre es la solución más limpia, lo más limpio en ese caso sería la vergonzosa formateada o reinstalar todos o cada uno de los paquetes que están más actualizados que su versión local, reconfigurar archivos .conf y rezar por que nada mas este roto.

 

En fin, en resumen testing es para los usuarios que realmente saben que están haciendo y que en su caso se toman el tiempo de subir reportes de bugs y fallos o actualizar el estatus de paquetes o para chavales con síndrome de versionitis, para trabajar y para cosa seria, testing esta fuera de rango.

Feliz cumpleaños Arch!

Estaba buscando un buen tema con que regresar a este blog y nada mejor que la mencion del 10 aniversario de un proyecto de software libre y mi distro favorita: ArchLinux.

Hoy, hace 10 años el programador canadiense Judd Vinet anunciaba la liberacion de la primera version de ArchLinux nombrada HomerCon un anuncio algo optimista:

News: Arch Linux 0.1 (Homer) released
2002-03-11 – Judd Vinet
I’ve finally got a bootable iso image on the ftp site. The bad news is that you don’t get a pretty interactive installer. But if you wanted one of those, you would have gone with RedHat, right? ;)

Here’s a short list of some future plans for 0.2:

Document ABS (Arch Build System) and provide a cvs-like update method so people can start building their own packages.
Finish the contrib area and start posting third-party packages.
Finish pacman 1.2 — this will allow you to update your entire system with the latest stable version of all packages, all with one command.
Add a pretty interactive installer. ;)
Add more documentation — our docs really suck right now. Please! If you have questions, just ask! Also, if you want to help out in any way, please let me know. I’m a student so my free time comes and goes at the will of my evil profs.
I’ll try to get the docs up for ABS (Arch Build System) which, IMHO, is one of the best advantages of Arch. With ABS, you can easily create new packages, and it’s trivial to rebuild existing packages with your own customizations.

And on that note, if you start to use the ABS and build your own packages, I welcome your submissions. My “development team” is working on a contrib area as we speak. ;)

Anunciando cosas como la temprana version de pacman, el modelo ABS o reconocer que su documentacion daba bastante que desear en ese tiempo se anunciaba este primer release de Arch.

Ahora podriamos decir que la documentacion ha mejorado un poco ;)

Felicidades Arch Linux!

Pulseaudio en KDE + ArchLinux

Siguiendo la guía de instalación de KDE en ArchLinux, vienen estos miniposts de pequeñas configuraciones o mejoras para el escritorio.

Que es pulseaudio

PulseAudio (antiguamente PolypAudio) es un servidor de sonido multiplataforma, capaz de funcionar por red. Funciona bajo sistemas compatibles con POSIX como GNU/Linux y otros sistemas operativos como Microsoft Windows. Se pretende que sea un reemplazo para el servidor Enlightened Sound Daemon.

Las características principales de PulseAudio incluyen:

Control de volumen independiente por aplicación.
Una arquitectura extensible basada en plugin con soporte para carga de módulos.
Compatible con la mayoría de aplicaciones de audio.
Soporte para múltiples fuentes de audio y skins.
Operación de baja latencia y soporte para medición de latencia.
Capacidad para descubrir otros ordenadores en la red local que utilicen PulseAudio, y reproducir sonido directamente hacia sus altavoces.
Posibilidad de cambiar el dispositivo de salida de audio de cualquier aplicación mientras se está reproduciendo el sonido.
Una interfaz de línea de comandos con funcionalidades de scripting.
Muestra de conversión incorporada y funcionalidades de muestreo.
Capacidad para combinar múltiples tarjetas de sonido en una sola.
Capacidad para sincronizar múltiples flujos de reproducción.
Detección dinámica de dispositivos de audio Bluetooth.

KDE, a diferencia de Gnome, por defecto no maneja pulseaudio, viene con alsa, hay configuraciones y paquetes para hacer funcionar a pulseaudio sin problemas, pero a menos de que estrictamente sepamos que necesitamos manejar pulseaudio, o tenemos alguna configuracion o equipo avanzado de audio pues es bueno cambiar a un sistema de sonido un poco mas avanzado como lo es pulseaudio.

Primero que nada instalamos pulseaudio, su conector con alsa y una li9breria para que pulse y flash se lleven bien:

pacman -S libcanberra-pulse pulseaudio pulseaudio-alsa
Leer más »

Unity en ArchLinux

Unity es un proyecto de canonical para unificar el escritorio de Ubuntu para diversas plataformas (movil, tablet, escritorio y TV). He de confesar que no es mi escritorio favorito. Por ser un proyecto desarrollado para Ubuntu existe la falsa creencia de que solo se puede utilizar completamente en Ubuntu, nada mas falso que eso.

En ArchLinux existe el proyecto Ayatana, que pretende empaquetar, compilar y modificar las fuentes de software de ubuntu/unity para ser utilizables en ArchLinux, y para nuestra sorpresa tienen su propio repositorio.

NOTA: Esta instalacion de Unity fue hecha sobre un sistema ArchLinux arquitectura i686, de momento este repositorio tiene paquetes solo para arquitecturas de 32 bits , con Gnome 3.2 y los drivers graficos previamente instalados.

Agregar el repositorio de Ayatana

Simplemente agregamos este repositorio al principio de nuestra lista de repos en el archivo /etc/pacman.conf:

[ayatana]
Server = http://repo.ayatana.info/

Leer más »