*nix pro

Podemos leer en El País (entre otros stios) que Sun compra Oracle^W^W^WOracle compra Sun por 5,7 Gigaeuros (aprox.). Parece que las campanas de boda con IBM acabaron en amarga ruptura, y no se sabe quién lloró más: si Sun por no saber cuál iba a ser su futuro, o IBM por no poder “librarse” de un competidor.

Ahora la cosa está más clara: Oracle, el gigante de las bases de datos, va a poder dar una solución “llave en mano” con todos los niveles cubiertos: servidor+S.O., base de datos y pila de servicios de aplicaciones (Glassfish, etc). Hay quien opina que Oracle estará tentado de deshacerse del “lastre”, pero lo cierto es que tiene en su mano una oportunidad dorada de situarse en una posición inmejorable no sólo en su sector de mercado, sino en otros donde su presencia es testimonial o inexistente, por un coste bajísimo en I+D.

Sun tiene unas tecnologías muy interesantes y un fuerte compromiso con el Código Abierto. Oracle tiene un gran producto y una visión y gestión impecables. Lo mejor de ambos mundos podría beneficiar no sólo a la empresa resultante, sino al mercado en su conjunto. ¿Vivimos en tiempos interesantes (en el sentido del proverbio chino)?

Ya me he ocupado anteriormente de las relaciones entre Sun e IBM. Pero lo que ayer saltó a los medios es la posibilidad de la adquisición de Sun por parte de IBM. ¿Alguien se extraña? Veamos.

Sun ha estado últimamente acicalándose y tomando decisiones interesantes (apertura del código de Java, de {Open,}Solaris y de ZFS…) y otras algo más controvertidas (compra de MySQL, cambio del símbolo bursátil de la empresa de SUNW a JAVA, abandono de las estaciones de trabajo basadas en UltraSPARC…). Aparentemente, no hay una estrategia clara definida. En realidad, es la consecuencia lógica (o no tanto) de haber retrasado ciertas tomas de decisiones hasta momentos que han parecido más propicios. Una empresa basada en la tecnología que trata de alejarse del mundo de los servidores (donde ocupa el cuarto puesto mundial, que no es poco) y de abrazar el paradigma “SaaS” (Software as a Service) basándose en soluciones de código abierto. Un enfoque que puede ser válido, pero que se ha tomado tarde y en circunstancias económicas revueltas.

No queda totalmente claro qué sacará IBM del trato, de producirse. ¿Aumentar su cuota de mercado en servidores? Sí. ¿Obtener patentes? Sí. ¿Otro Unix? Con su AIX y Linux, no es un valor a destacar. ¿Procesadores UltraSPARC? Con los de Intel/AMD y los Power propios de IBM, no parece necesitarlos. ¿Una cartera de clientes? Tal vez, pero no creo que sea ese el objetivo. ¿Acabar con la competencia? Aparte de la bronca de los antimonopolistas, Sun e IBM juegan con valores diferentes que no tienen por qué atraer a los mismos clientes.

Sun e IBM. Dos culturas empresariales distintas. Dos enfoques para un mismo problema. De su “fusión” puede salir algo interesante. Pero también podría ocurrir que, de producirse la compra, fuera seguida por una venta selectiva de las partes que menos le interesase. En cualquier caso, yo personalmente estoy agradecido a Sun por algo que no se paga con dinero.

En un momento crítico de mi carrera, involucrarme en el mundo de Solaris y OpenSolaris, adquiriendo parte de la experiencia con máquinas de Sun que compré por internet, me hizo recuperar la fe en mi oficio. Por eso, pase lo que pase: gracias, Sun; y buena suerte.

ACTUALIZACIÓN 20090406: puede que al final, Sun haya de seguir esperando quien la saque a bailar.

En estos tiempos de crisis, la gente mira más el céntimo que antes. Tal vez por eso, y tal vez porque algún día tenía que ser, se busca en la tecnología la respuesta no a “hacer más con los mismos recursos”, sino  a “hacer lo mismo con menos recursos”.

Asus abrió de forma práctica el mercado de los ultraportátiles, a medio camino entre el (al parecer) casi extinto de los PDA (absorbido por los limitados “teléfonos inteligentes”) y el boyante de los portátiles. Intel ha metido mano en estos últimos, desarrollando un completo juego de circuitos (o “chipset”, como dicen los que no saben español :). El mercado ha tratado de aprovechar esta tecnología haciendo uso de los mismos recursos lógicos empleados en sus hermanos mayores: Linux y *indows (sin olvidar a los manitas que han instalado OpenSolaris o MacOS).

Sin embargo, instalar *indows requiere más memoria y disco de lo que sería deseable para abaratar costes, al tiempo que las versiones de Linux a veces están adaptadas mediante la seria mutilación de sus cualidades. Los más aventurados han tratado de reducir los recursos que usan sus distribuciones favoritas para lograr una funcionalidad más idónea sin despilfarrar memoria o disco.

Pero Intel tiene otras ideas en mente: mediante el proyecto moblin, quiere crear el complemento lógico de su sistema físico. Tras comprar OpenedHand y adaptar su proyecto Clutter para el entorno gráfico, desarrollar ConnMan para sustituir a NetworkManager, y diversas cuestiones de arquitectura, se han planteado como objetivo principal que su particular distribución de Linux (basada en Fedora y construida actualmente con XFCE) arranque en cinco segundos. ¿Lo conseguirá?

No lo sé, pero la versión alfa 2 actualmente disponible (se espera que la definitiva aparezca en 2010) no requiere mucho más para arrancar desde una memoria USB en mi Aspire One… Creo que merecerá mucho la pena seguir la evolución de este proyecto.

Migrar desde Fedora 8 a Fedora 10 es una tarea posible y casi indolora (lo he comprobado). Sin embargo, para mi portátil decidí ir directamente a la instalación desde cero, preservando mis datos, por supuesto. Quería acostumbrarme a algunas de las aplicaciones que vienen en el DVD (algo de esto contaré en mi otro diario, no tecnológico), y de paso hacer un poco de limpieza (creo que he ido actualizando desde Fedora 5 o 6, así que ya tocaba).

Fiel a su filosofía de poner lo último, Fedora 10 suspende, hiberna y acelera la tarjeta gráfica de mi portátil del trabajo (Dell Inspiron 6400)… pero con mi fiel Acer Aspire 1400, falla en las tres tareas según se instala. Anteayer realicé una actualización (las he ido probando todas) que ha dejado las dos primeras en perfectas condiciones operativas, mientras que la aceleración 3D sigue siendo deficiente, pero al menos está ahí (ATI Radeon Mobility M6). Por cierto, que el paquete “bueno” es el xorg-x11-drv-ati-6.9.0-63.fc10.i386, los anteriores 61 y 62 hacen que X se pegue el tortazo nada más arrancar GDM.

A día de hoy, todas las cosas complicadas están aparentemente funcionando. Además de las alabanzas a la red, como dije en mi anterior artículo, he de decir que desde un comienzo ha estado funcionando la tarjeta de red inalámbrica (Intel Pro Wireless 2915), además de una basada en ZyDAS 1211. Esta última no es que sea una maravilla, pero su sensibilidad a la orientación nos puede permitir una bonita “caza del zorro”. Quien no sepa lo que es, que no pregunte :P En cualquier caso, la gracia del asunto es que NetworkManager reconoció ambas simultáneamente y mostraba las redes que se captaban con cada una de ellas de manera independiente.

El resto de características, incluyendo el arranque gráfico con Plymouth (no olvidéis poner “vga=0×315″ al final de la línea de arranque si vuestra tarjeta no está soportada pero tiene modos VESA) están más que documentadas por ahí. No hablaré de la versión de Gnome o Firefox que trae de serie, pero sí de lo muy recomendable que es añadirle el repositorio yum de  rpmfusion para complementar los paquetes instalados (multimedia incluido). Gracias a ellos estoy pasando (por última vez, espero :) mi colección de CD de música a mp3, además de a flac y ogg Vorbis.

Así pues, tras un mes de uso puedo recomendar Fedora 10 para casa, para el trabajo y para el ocio… sólo me falta tener el tiempo y el espacio en disco para ponerme en serio con OpenSolaris 2008.11 y así poderlas comparar seriamente.

Hace ayer justo un par de semanas tuve uno de esos días de trabajo en los que las tareas llegan espaciadas y con cuentagotas. Y, además, más tarde de la hora a la que debería salir (¿tenemos realmente horario los administradores de sistemas?). Así que, para pasar el rato, decidí actualizar mi portátil del trabajo de CentOS 5.0 (qué gran sistema; todos sabemos de quién lo hereda) a Fedora 10. El motivo principal para mí eran las mejoras en la gestión automática de redes con NetworkManager. Sólo por eso, estaba dispuesto a darle una oportunidad a Gnome y su entorno integrado de red, al que nunca me he acostumbrado.

Algunas noches (como la de ayer) nos toca hacer pasos a producción, y la verdad es que la perspectiva teórica de quedarnos sin red me producía escalofríos. Nunca nos había ocurrido, eso es cierto; pero no sólo dependemos de nuestra conexión ADSL para salir al exterior: el CVS principal también está en nuestras instalaciones, por lo que si nos quedásemos sin conexión, tendríamos que aplazar toda la operación a otro día, con las molestias que ello acarrea.

Así que, animado por la posibilidad de compartir red y servir a otros a través de una conexión HSDPA, GPRS o similar, hice copia de mis datos, instalé Fedora 10 y restablecí mis datos. Todo ello, en las pausas entre tareas de subidas a preproducción. Después de cambiar unos ajustes, o dejé todo más o menos a mi gusto. Al día siguiente me embarqué en la tarea de migrar mi correo a Evolution, para darle una oportunidad más (en el pasado lo encontré demasiado lento). Pero esa es otra cuestión.

Cada vez que alguien me preguntaba por qué me había pasado a Fedora 10 en el trabajo, le contestaba lo mismo: “por la posibilidad de compartir la conexión de red”. No imaginaba entonces que ese mismo viernes nos iba a salvar la vida (más o menos).

Teníamos una subida a preproducción, y nuestro proveedor de ADSL tuvo una avería de las grandes (que llegó a durar más de 18 horas). Había que  tener acceso al CVS desde el exterior, así como enviar las aplicaciones, además de que varios miembros del equipo necesitaban comprobar el correcto funcionamiento. ¿Qué hacer?

¡Fedora 10 al rescate! Conecté al portátil el módem USB HSDPA de Vodafone para salir a internet, conecté la red de cable para acceder a la red local y preparé una red inalámbrica compartida para que mis compañeros pudieran conectarse (afortunadamente, todos teníamos portátiles con conexión Wi-Fi). Sólo tuve que añadir a mano la ruta implícita para salir a internet, el resto funcionó gracias a la magia de NetworkManager.

El CVS seguía sin verse desde afuera, pero me pude traer los proyectos a mi ordenador y enviarlos en bonitos paquetes .tar a los servidores correspondientes. Una vez allí, compilamos los proyectos, los desplegamos (bonito palabro) y los echamos a andar como normalmente. Mientras tanto, mis compañeros probaban las aplicaciones, actualizaban las bases de datos o editaban las configuraciones para ajustar los parámetros que habían cambiado con toda normalidad, salvo que la velocidad de acceso era algo menor.

Gracias a este mecanismo, pudimos ahorrarnos tener que conectarnos el sábado para hacer la misma tarea, pero cada uno cómodamente en su casa en vez de pasar frío en la oficina un viernes desde las 16:30 hasta eso de las 20:00. Espera, al final tal vez no fue tan buena idea después de todo :P

Este mes de mayo, la distribución de OpenSolaris denominada Indiana y cuyo nombre oficial es openSolaris 2008.05 (para x86) ha visto la luz. De sus cualidades muchos han hablado ya, así que mi análisis será bastante esencial y se centrará en dos cuestiones fundamentales: qué es y para quién es.

La paulatina transformación de Sun en una empresa de servicios basada en código abierto tiene como piedras angulares sus servidores (la parte física) y su versión particular de *nix, Solaris (la parte lógica). Esta última parte ha ido siendo abierta a la Comunidad OpenSolaris para que los desarrollos que se hagan en ella constituyan la base de las siguientes versiones de Solaris. Más o menos. Los intentos de Sun de aclarar sus intenciones, reteniendo cierto control de calidad y marca, pero permitiendo las colaboraciones externas, merecerían otro artículo.

Fruto de esta apertura son las diversas consolidaciones de lo que se ha llamado Nevada, y que no es otra cosa que las versiones que se consideran más o menos estables del código que fue de Solaris y que ahora está mutando a OpenSolaris. Con este código la Comunidad puede hacer las distribuciones que prefiera (al estilo de Linux), y una de ellas es, precisamente, la de Sun. OpenSolaris no es, por lo tanto, un Sistema Operativo completo. Las distribuciones que con su código se construyan, sí pueden serlo. Una de ellas es la que ha recibido el nombre OpenSolaris 2008.05, también conocida como Indiana. Espero que a estas alturas esté un poco más claro qué es. Sólo quiero añadir que se trata de una distribución live, es decir, que se puede ejecutar directamente desde el medio (CD-ROM) para probarla, sin necesidad de instalarla en el disco del ordenador; aunque también es posible hacer esto último en una partición especialmente dedicada a ello, ocupando unos 3G de espacio.

Para quién es es una cuestión ciertamente delicada, no tanto por el planteamiento teórico sino por cómo se ha llevado a la practica. En efecto, parecería lógico que Indiana (orquestada por Ian Murdock, cofundador de la distribución Debian) heredase de Solaris 10 (la última encarnación de este *nix) la mayor parte de sus características y orientación. Solaris, me consta, funciona fantásticamente bien en las máquinas de Sun (UltraSPARC y x86_64), pero no tan bien en las ajenas (x86). La clave, como siempre, está en los controladores para la pléyade de dispositivos que hay en el mercado.

Indiana pretende ser una primera incursión a este mundo tan variopinto y caótico que son los ordenadores cuyos componentes y calidad no puede controlar el fabricante del Sistema Operativo. En pocas palabras, Indiana está dirigido a aquellos usuarios precursores cuyas máquinas son montadas por otros fabricantes o incluso por ellos mismos, con componentes más o menos comunes, pero de origen “desconocido” (para Sun). Y estos usuarios no son necesariamente los que ya estaban habituados a Solaris.

En efecto, lo más probable es que, por número, si estas personas han estado ejecutando un sistema tipo *nix en sus ordenadores con antelación a Indiana, se haya tratado de alguna distribución de Linux o *BSD. Y para ellos lo más atractivo sería, sin duda, un sistema en el cual puedan compilar sus aplicaciones favoritas. Un sistema donde las herramientas del nivel de usuario (en el sentido de *nix, por supuesto) sean familiares en comportamiento y sintaxis. Un sistema, en definitiva, en el que el entorno visible (no solo el escritorio, que en este caso es Gnome) sea compatible con lo que ya conocen: herramientas de GNU, incluyendo los compiladores y bibliotecas más populares (¿alguien ha dicho Gtk+). Y así es Indiana.

¿Quiere esto decir que se quiere dejar de lado a los usuarios tradicionales de Solaris? Por supuesto que no. Pero en esta versión, el énfasis se ha puesto en la captación de adeptos. Prueba de ello es que, aunque todas las herramientas tradicionales de Solaris están disponibles, la variable PATH antepone el directorio que contiene las de GNU a aquéllas. Naturalmente, el “arreglo” (si no tenemos ya nuestra propia definición de la variable) es trivial.

Para terminar, mi experiencia con Indiana ha sido breve, pero interesante. Nada más arrancar el entorno gráfico, me preguntó a cuál de las redes inalámbricas quería conectarme, que ya es bastante. La instalación al disco local (emulado mediante VMWare) fue fácil, con una única sorpresa: al elegir la zona horaria, pareció creer que España está en África. Y, hasta ayer al menos, no era así :P

Leyendo el diario de Jonathan Schwartz (actual Presidente de Sun, por si alguien no lo sabía), me entero de sendas noticias que tienen por sí solas notables repercusiones, pero que en conjunto dan una idea más clara de cuál puede ser la estrategia de Sun para el futuro: el acuerdo con IBM y el cambio del identificador de las acciones de SUNW a JAVA. ¿Qué pueden significar estas dos noticias combinadas?

La primera de las noticias nos habla de un acuerdo por el cual IBM dará soporte para Solaris en su propia gama de servidores System X y BladeCenter, convirtiéndose en OEM de Solaris. Sun quería separar su negocio de servidores del negocio de Solaris (y las aplicaciones, me imagino), y lo que está haciendo para conseguirlo es hacer que otros puedan instalar Solaris fácilmente en sus servidores (haciendo una versión para x86 y x64), logrando que otros incluso lo añadan a su catálogo (como HP) y, finalmente, poniéndolo como producto soportado.

Para IBM puede significar tener una oferta más para sus clientes, compuesta hasta ahora por AIX (el *nix de IBM), Linux (para varios servidores de gama baja) y ahora Solaris (cuyo rendimento supera al de Linux conforme aumenta el número de procesadores); y también ofertan *indows para los clientes que lo pidan, que alguno habrá, digo yo.

¿Y para Sun? Contar con la red de distribución de IBM, aumentar su visibilidad, tal vez incluso ver su nombre asociado al del gigante de las tres letras rayadas. A veces, más que otra cosa, es una cuestión de percepción.

Y de percepción va el juego, pues la segunda noticia habla de cambiar el identificador de bolsa de SUNW (Stanford University Network Worldwide, perdón, Workstation) a JAVA, que según parece es una marca más conocida para el gran público. Decisión que ha sido lamentada por muchos (entre los que me cuento), pero que sólo el tiempo decidirá si está bien tomada. A fin de cuentas, para bien o para mal, las volubilidades del mercado no las deciden los ingenieros.

¿Qué hay detrás de todo esto? Está claro: un cambio sutil de imagen (puede que acompañado en el futuro de otros cambios menos sutiles) y una reorientación hacia su actividad empresarial. Al separar las líneas de servidores y de servicios (fijáos la curiosa dualidad), Sun puede estar haciendo que la parte que le resulte más rentable apoye a la que menos lo esté siendo. Y si en el futuro se decide que una de esas partes ha de caer en letargo, puede hacerse sin socavar los cimientos de la empresa.

La duda que muchos albergan es si la línea de servidores de Sun y el procesador UltraSparc en todas sus encarnaciones está en peligro. No me atrevo a arriesgarme a predecir el futuro en este mercado de los servidores (es sabido que es mucho más difícil sobrevivir si vendes hierro que programas), pero las innovaciones que estamos viendo salir de las factorías de Sun (de las cuales la última es el UltraSparc T2, capaz de ejecutar hasta 64 hebras de ejecución simultáneas) hacen palidecer a la competencia (Intel y AMD están comenzando a ofrecer procesadores con cuatro núcleos de UNA sóla hebra de ejecución). Si existe un mercado para servidores de gama alta, y existe, está claro para mí que Sun tiene un lugar en él.

Mientras tanto, que Sun decida tener dos unidades funcionales, una de ellas dedicadas a la parte de los Sistemas Operativos y las aplicaciones, no parece tan mala idea. Y hacer alianzas con quien siente tener un hueco en ese segmento parece la opción lógica. Para ambos.

Por fin se inaugura oficialmente la página de la Comunidad de habla hispana de OpenSolaris. Gracias a la colaboración de muchas personas (entre las que cuento mi modesto esfuerzo traduciendo algunas de las páginas), hoy podemos finalmente disfrutar de este centro de interés dentro del mundo de OpenSolaris. Enhorabuena y gracias a todos los que lo han hecho posible.

Cabe añadir que este diario tendrá una orientación más inclinada hacia el proyecto OpenSolaris a partir de ahora. Mientras tanto, los que estén ávidos de contenidos pueden visitar el agregador de diarios de los miembros más activos de la Comunidad. Su lectura siempre resulta interesante.

Con motivo de las conferencias Java One, Sun ha ido anunciando una serie de novedades: Java como producto GPL (salvo las partes con licencias de terceros, a rehacer en su momento), JavaFX/JavaFXScript, etc. Ahora le llega el turno a Solaris: de ser licenciado con la licencia de Sun CDDL, pasará a serlo con la popular Gnu Public License. ¿Cuáles son sus motivos, cuáles serán las consecuencias? Como ya dije en su momento, algo está cambiando en Sun. Si el cambio representará para la compañía más garantías de supervivencia o no, el tiempo lo dirá. Mi impresión es que sí, pero de maneras tal vez un tanto sutiles para poder apreciarlas ahora. Hace no demasiado, Sun anunció que Java se licenciaba bajo GPLv2, un paso ansiado por muchos. Ahora, Sun está a punto de licenciar (Open)Solaris en las mismas condiciones, en lugar de la actual CDDL. Los motivos, según algunos, son reducir costes de desarrollo, posiblemente incorporando código de su más directo competidor, Linux. Claro que la veda se abre también en el sentido inverso. Lo cierto es que, en ambos casos, se trata de algo técnicamente bastante más complicado de lo que parece. Pero mucho más. Las consecuencias (difíciles aún de prever) serán, entre otras, una mayor aceptación en la comunidad de Solaris, redundando también en una mejor adaptación al entorno físico (léase: diversidad de sistemas y periféricos) basado en la arquitectura x86. Teniendo en cuenta que Sun ya vende sistemas x86, ¿para qué querría Sun soportar sistemas que no vende? Fácil: para facilitar la migración a Solaris en los sistemas ya instalados de la competencia. Después de la incorporación de Ian Murdock, llega la noticia de que Sun quiere desarrollar un proyecto denominado Indiana, es decir, “un Linux mejor que Linux” (Solaris). Todo lo anterior se une a esto en una imagen más coherente. Y os lo voy a contar. Solaris tiene una gran solidez interna a diferencia de Linux, que parece estar optimizado para un caso más general y para hasta 4 procesadores. Pero las herramientas comunes del sistema están bastante más evolucionadas en Linux. Sun necesita cierto apoyo en esta área, y sin embargo no desea tomar prestado sin dar a cambio. ¿La solución? Hacer aún más abierto su proceso de desarrollo: adiós CDDL, hola GPL. Sun aún puede hacer dinero con el soporte y con la venta de sistemas. Pero es sabido que el mercado del hardware es bastante criminal: márgenes reducidos, competencia abrumadora, clientes que en más de una ocasión (seamos sinceros) prefieren un buen descuento a pagar calidad (y luego quejarse a gusto)… Sun necesitaría un factor diferenciador para calar en la mente de los potenciales compradores. Y lo tiene: SPARC. Pero falta convencer a los clientes de por qué es bueno. Los ingredientes están, sólo falta la receta. ¿Qué os parece esta?

• Abrir Solaris y captar clientes con sistemas x86 variopintos
• Migrar estos clientes a sistemas grandes basados en SPARC
• ¡Beneficios!

Mientras tanto, la comunidad de los programas libres se beneficia, los clientes se benefician y Sun se beneficia. Al menos, en teoría. Seguiremos los acontecimientos con interés.

Nos lo cuenta él mismo en su diario. El bueno de Ian, más conocido por ser el fundador y líder del proyecto Debian de GNU/Linux desde 1993 hasta 1996, Presidente de Linux Standard Base, y hasta hace muy poco Director de Tecnologías de la Linux Foundation, pasa a formar parte de la plantilla de Sun como Director de Estrategia de Sistemas Operativos. Hasta ahí, bien. Ahora, ¿qué significa para Ian y para Sun esta nueva etapa?

Desde hace un tiempo (algunos dirán que desde que Jonathan Schwartz es el máximo responsable de la compañía), Sun está cambiando el rumbo. Si a mejor o a peor, económicamente hablando, el tiempo lo dirá. Sin embargo, como Informático y Administrador de Sistemas, he de decir que Sun, y la comunidad *nix, está viviendo en tiempos interesantes, sea lo que esto signifique.

Supónese que Ian va a tratar de “reducir la distancia entre Linux y Solaris”. ¿Cómo? ¿Acercando Linux a Solaris, o acercando Solaris a Linux? ¿Quién necesita acercarse más a quién? Si hablamos de robustez, Informática de Altas Prestaciones y eso que llaman norma industrial, está claro que Linux necesita más acercarse a Solaris que lo contrario. Pero una cosa que Solaris sí necesita es soportar mayor número de periféricos. ¿Por qué? ¿Acaso no lo están ya todos los de sus sistemas? Sí, pero Sun tiene otros objetivos. Y no es exactamente hacerse con el entorno de escritorio. O tal vez sí.

Si Sun contrata a alguien, no es para mejorar Linux, sino Solaris. Esto parece evidente. Pero dada la nueva estrategia de código abierto, es muy posible que aquello acabe también ocurriendo. Por otro lado, Sun sólo necesitaría mejorar en aquellas áreas que tenga debilidades, siempre que afecten a un segmento de mercado en el que tenga interés… El escritorio, fuera de los entornos corporativos donde tenga ya sus servidores o estaciones de trabajo, no parece un segmento prioritario para Sun. Pero claro, si invertimos el orden de dependencia, la cosa cobra otro sentido: introducirse en los entornos corporativos donde ya existan escritorios basados en Linux para sustituirlos por Solaris como parte de una estrategia integral que implique a servidores Sun. Solución completa a todos los niveles.

Y para este objetivo, contratar a alguien que ha estado implicado en el desarrolllo de una distribución completa de Linux, desde la parte tecnológica hasta (y esto es muy importante) la filosófica, tiene sentido. No en vano, OpenSolaris tiene una filosofía basada en la de Debian. ¿Casualidad? No lo creo.