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

[Jordi]

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/