[cafe-sd] Quedada Madrid OSUG de comunidad local OpenSolaris

Jordi jordi en sindominio.net
Mar Feb 16 01:13:26 CET 2010


On Mon, Feb 15, 2010 at 05:48:08PM +0100, Quique wrote:
> Duh.  No es tan simple como lo presentas.  GNOME tambi�n est� disponible
> en GNU/Hurd, �debo entender que tambi�n est� preparado para sustituir a
> otros sistemas en el escritorio?

Y no s�lo eso: en el equipo de empaquetado de GNOME para Debian estamos
debatiendo (y de hecho lo hablaremos con Stormy, de la GNOME Foundation
esta semana) la cada vez m�s evidente RedHatizaci�n de GNOME. Cada vez
entran m�s y m�s "features" que se aceptan sin m�s porque parecen una
gran idea pero luego, a poco que rascas, se ve que la implementaci�n
aceptada est� plagada de "RedHatismos", con las que otras distribuciones
tenemos que lidiar. A�n podemos dar gracias a que la grand�sima mayor�a
de los usuarios de GNOME lo son a trav�s de Ubuntu, que suele producir
algunos hacks a toda prisa para superar estos problemas. Dos ejemplos:

Un ingeniero de Red Hat se mete en el redise�o y reescritura parcial de
GDM, que ya le hac�a falta porque arrastraba c�digo super viejo, de la
etapa de GNOME 1.x. En el camino, decide "simplificar" el soporte de
asignaci�n de VTs. As�, el GDM 2.20 se "asignaba" la primera VT libre
del sistema (tradicionalmente la s�ptima, estando las 6 primeras ocupadas
por /bin/getty), y si se iniciaba otra sesi�n, se buscaba la siguiente
libre, etc, mediante una especie de gestor de VTs. En GDM 2.24 (la versi�n
reescrita, GDM arranca en el VT 1. Porque todos sabemos que *todas* las
distros han pasado a tener las X en la primera, �no? Tambi�n, de paso,
quitan el configurador gr�fico, porque RedHat tiene otra cosa para hacer
eso.

Resultado: en Fedora, el GDM va de categor�a. En Ubuntu han hecho no s�
qu� hack fr�gil para el tema de las VTs, y el configurador, si no me
equivoco, no existe:

http://bobthegnome.blogspot.com/2010/02/gdm2setup.html (visto hoy en Planet)

En Debian, sin embargo...

       gdm | 2.20.7-4lenny1 |        stable | source, alpha, amd64, arm, armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc
       gdm |  2.20.10-1 |       testing | source, amd64, armel, hppa, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc
       gdm |  2.20.10-1 |      unstable | source, alpha, amd64, armel, hppa, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc

(m�s que nada porque se decidi� rechazar las soluci�n de Ubuntu, y otras
propuestas para acercar el funcionamiento a lo que hace Fedora de una manera
m�s flexible han tenido alg�n encontronazo con los �console power users� de
debian-devel...)

RedHat empieza a idear los paquetes *Kit para sustituir algunas tecnologias
por otras m�s modernas que usen DBus, etc. Entre otras, se inventan el
PackageKit, que es un backend/frontend para gesti�n de paquetes supuestamente
neutral. Evidentemente, RedHat financia el backend RPM, pero no el de Debian.
Hasta ah�, se puede entender. Excepto que la especificaci�n de PK dice que
los paquetes nunca jam�s deben comunicarse con el usuario para nada, por
lo que no hay ninguna provisi�n para esto en la API. A alguno le suena algo
que se llama "debconf"?

Pero volviendo al tema OpenSolaris, muchas de estas nuevas funcionalidades
est�n basadas en tecnolog�a bastante "bleeding edge", que tal y como pinta,
tengo mis dudas de que lleguen a OpenSolaris en un tiempo razonable.

Por ejemplo, se est� migrando muchas tecnolog�as de la espina dorsal de
GNOME desde HAL (Hardware Abstraction Layer) a libudev. Que yo sepa,
udev es una tecnolog�a Linux-only y no hay una capa de compatibilidad en
OpenSolaris. Con esto, mucha funcionalidad nueva del GNOME va a quedar
fuera de OpenSolaris (y de Debian GNU/kFreeBSD, de ah� nuestra queja).

Es m�s, GNOME 3.0 est� decidido que depende de OpenGL (GNOME Shell usa
clutter, y clutter depende del soporte de GL en el servidor X). No s�
c�mo est� el tema del soporte de DRI en las X de OpenSolaris, pero si no
hay, no habr� GNOME 3.0.  O si lo hay, m�s vale que se est�n currando
algo parecido a KMS (Kernel Mode Setting) para el kernel de OpenSolaris,
porque a partir de ya, muchos drivers (sobre todo el de Intel y ATI) van
a retirar el soporte para kernels sin KMS, ya que al parecer es mucho
m�s estable.

http://en.wikipedia.org/wiki/Mode-setting#Location

De toda la hebra sobre OpenSolaris, siempre he pensado que lo que m�s
envidia daba es lo del snapshotting del sistema antes de hacer un
upgrade. Si te peta, haces un rollback y punto. Estoy muy seguro que en
cuanto btrfs sea el sistema de ficheros "por defecto", esta ser� una
funcionalidad que se podr� encontrar en cualquier distribuci�n de Linux
moderna.

Como cosa m�s inmediata, parece que los parches para "snapshot merging"
de LVM est�n en la cola de inclusi�n. No es ni de lejos un ZFS, pero
�til va a ser un rato.

Mi visi�n como observador del rollo Sun/Oracle y la andadura de
OpenSolaris por los prados del software libre no es muy alag�e�a... veo
demasiadas amenazas para una comunidad externa a Sun demasiado poco
implantada, y creo que la CDDL tiene buena parte de la culpa. Si al
menos los hacks para OpenSolaris fuesen reaprovechables en Linux, habr�a
algo de est�mulo para portar drivers de un lado a otro, pero siendo
las licencias incompatibles en ambos sentidos, y con la incerteza que
hay sobre todo lo que era de Sun, no invita demasiado, y esta era la
impresi�n bastante generalizada en el FOSDEM de la semana pasada.

Vaya chapa... Quique, te dije que mejor un poleo, que a mi el caf� me
altera demasiado...

Jordi
-- 
Jordi Mallach P�rez  --  Debian developer     http://www.debian.org/
jordi en sindominio.net     jordi en debian.org     http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/


M�s informaci�n sobre la lista de distribuci�n cafe