Artículo muy interesante sobre el debate Windows-Linux

[des_hundalasiliah]

En esta página (de Microsoft), se dedican a comparar Windows con Linux, y el que lo escribe asegura basarse en datos objetivos. Os va a encantar, es para partirse de risa (¿Windows más barato que Linux? ¿Las colgadas de Linux son peores que las de Windows?)

http://www.microsoft.com/spanish/msdn/c ... art184.asp

Windows vs. Linux, Mitos y Realidades


Por Carlos Alejandro Pérez

Introducción

Muchas veces nos hemos preguntado lo mismo: si Windows es tan malo como dice la gente que lo detracta y si Linux es tan bueno como dicen los que lo usan. Si Open Office es equivalente o mejor que Microsoft Office. Y así, las preguntas que podríamos enunciar son muchas y algunas respuestas, ciertas o no, están ya insertadas en el imaginario popular.

Sin embargo, como gente que trabaja todos los días en IT, tenemos que darnos cuenta de que uno de nuestros roles es esclarecer en alguna medida esta cuestión. ¿Cómo podemos hacerlo? Quizás hablando desde alguna tribuna Microsoft, nuestro mensaje no sea tan creíble.

Igualmente, el escribir sobre Linux en una publicación para una comunidad devota a Microsoft es ciertamente un desafío, tanto como lo es expresar los hechos sin introducir ningún elemento subjetivo, máxime ahora que desde hace pocos días pasé a formar parte de la legión de MVP. Con esto en mente, pasemos a ver los mitos, y las realidades, desde mi humilde punto de vista, basado en ciertas experiencias recientes.
El escenario de las pruebas

En nuestra labor diaria, llevamos adelante muchas investigaciones, aún sin darnos cuenta. Investigamos cuando cae en nuestras manos un nuevo software, un nuevo sistema operativo, un nuevo service pack. Nuestra actividad nos exige eso constantemente; por eso, en 2003 decidí pedirle a nuestros alumnos de cuarto año de la carrera de Ingeniería en Sistemas de Información que hiciesen un trabajo práctico bastante importante: desarrollar una aplicación cliente-servidor con cliente pesado, más interfaz Web, más Web service, más servicio de mailing, con un COM ó un CORBA dando vueltas por ahí, todo servido por un RDBMS cliente-servidor. La dificultad era que exigí que la solución debiera involucrar a Windows y a Linux al mismo tiempo, es decir, seleccionar la mejor plataforma para servidor, y elegir la restante para el cliente, a libre albedrío de cada grupo de alumnos.

Como los alumnos no tenían ninguna experiencia previa con Linux, pensé que la propuesta era interesante, al menos para mí, ya que por fin podría ver cómo gente con ciertos conocimientos previos emitía un juicio de valor acerca de Windows y Linux. Les aclaré que la idea no era hacer un pugilato informático, sino determinar en base a experiencias propias qué plataforma era la mejor, desde su punto de vista de estudiantes avanzados, para la implementación de un sistema comercial en una empresa.

Eso fue en Agosto de 2003. Hace unas pocas semanas tuve el último resultado, y quisiera compartirlo con los lectores.

Pero antes de eso, quisiera exponer algunas consideraciones sobre Linux, y algunas aserciones que suelen circular en el ambiente de IT.

Algunos hechos sobre Linux

El sistema operativo Linux no es UNIX. Es más bien un clon de UNIX, o por lo menos así lo han expresado siempre sus defensores. Tanto los sistemas Windows NT como Linux son sistemas operativos con micronúcleo (microkernel). Los entusiastas de Linux argumentan que este núcleo, en el S. O. Linux, está escrito desde cero, sin haberlo copiado de ninguna parte. No obstante, en el proceso de reescritura mucha de la forma y método de UNIX se ha transferido, como se transmiten los genes a parientes no tan cercanos. Los comandos de UNIX se han transferido sin mayores cambios, la esencia misma de UNIX está presente en Linux. Sin embargo, esta pequeña diferencia se torna importante, como veremos más adelante. No haremos historia de esto, digamos sólo que actualmente el sistema operativo evoluciona en una forma descentralizada, donde no existe una organización que pueda determinar monolíticamente el camino o sentido hacia donde avanzar tecnológicamente con el producto.

La gratuidad de Linux se basa en modos de licenciamiento que no involucran transferencia monetaria alguna. Sin embargo existen restricciones, ya que también existe un contrato que limita y especifica las obligaciones de las partes, al igual que una EULA (End User License Agreement) de Microsoft. La restricción más importante es la distribución del código fuente en algunos casos, o bien la prohibición de guardarse las modificaciones para sí, sin darlas a conocer a la comunidad. Microsoft, en cierto modo y en ciertos casos, también tiene software de uso libre, tal como la Embedded Visual Tools, que se compone de IDE más compiladores, herramientas de depuración, emuladores binarios para los dispositivos móviles y documentación completa, la cual no tiene absolutamente ningún costo monetario. Microsoft, sin embargo, no distribuye el código fuente todavía, aunque Redmond ha comenzado tibiamente a liberar código en ciertos campos que considera viables para el aporte directo de la comunidad.

Hasta aquí las cosas, los canales de distribución sacan ventaja de este marco, produciendo versiones de Linux que están acondicionadas apropiadamente por el distribuidor para darle valor agregado que pueda cobrar. La distribución más importante de Linux es conocida por todos, la RedHat. Sin embargo, su sitio Web ha cambiado de tenor de una manera muy acentuada desde 2001 a la fecha. Lo que originalmente había comenzado como un sitio donde se impulsaba el código libre, con muchos hipervínculos para descarga de los binarios, fuentes y documentación, se ha transformado en un sitio con un marcado sesgo comercial, donde prácticamente los vínculos para descarga están ocultos en la ultima jerarquía de páginas, o donde la descarga de archivos está contraindicada por una cuestión de velocidad y del tamaño de los archivos a ser transferidos, en su mayoría imágenes de CD-ROMs en formato ISO, prohibitivo para todo aquello que no sea banda ancha.

Los canales distribuidores de Linux han diversificado su oferta, generalmente en estación de trabajo y servidor. Debido a que los distribuidores pueden alterar grandes porciones del sistema operativo, podemos esperar diferencias considerables en servicios de red entre una versión y la otra. Como era de esperarse, han posicionado como versión libre la estación de trabajo, mientras que los servidores los cobran a precios que suelen ir de unos USD 150 hasta más de USD 2.800 para procesadores Intel, y ciertamente cinco veces esa cifra para plataformas Mainframe. Estos montos son anuales, es decir, no es el costo del software - lo cual iría contra la licencia - sino es el servicio de soporte del canal distribuidor.

Esta es una diferencia importante con Windows. Uno paga Windows una sola vez, compra la licencia de uso, y en principio, no la debe pagar de nuevo cada año a menos que desee cambiar de versión o aumentar el número de licencias. Como las versiones de Windows salen aproximadamente cada tres años (meses más, meses menos) si hacemos números es posible que nos llevemos alguna sorpresa.(1)

Pero dejemos el vil metal de lado. Uno puede decidir no suscribirse a la licencia de soporte que ofrece el canal distribuidor, e intentar ir andar solo por el camino de Linux, utilizando la información disponible en la Web. Los canales más importantes publican la documentación de usuario final en varios idiomas, debido a aportes voluntarios de traductores en todo el mundo. Sin embargo, ciertos segmentos importantes del sistema operativo pueden no estar traducidos, o algunos paquetes tales como servidores de bases de datos pueden tener parcialmente hecha la traducción. Esto, para cierto segmento de usuarios y administradores, es un punto en contra, aunque convengamos que no determinante.
¿Linux consume menos recursos aún con interfaz gráfica?

Lo primero que se ha encontrado es que Linux no es "un sistema operativo liviano que funciona en una 486", como se suele decir por ahí. El kernel puede hacerlo, pero la utilidad entonces es nula para el usuario final.

Para entender esto, tendríamos que ver fundamentalmente la carga de la interfaz gráfica. La interfaz gráfica de Linux está basada en X-Windows (llamada por muchos, simplemente "X"), una tecnología que lleva el paradigma de cliente-servidor a las interfaces de usuario, que vio la luz a finales de los 80's de la mano de Digital Equipment Corp (DEC). En X-Windows, como en cualquier otro proceso de servidor, existe un servicio de interfaz y un cliente que lo consume. Ambos procesos suelen estar en la misma computadora, pero puede suceder que estén en equipos separados.

Nótese, sin embargo, que el concepto es diametralmente opuesto al del escritorio remoto de Windows: lo que sería el cliente de escritorio remoto en Windows, es el X-Servidor en X-Windows, y lo que sería el servidor donde se ejecuta el procesamiento en Windows Servidor, sería el X-Cliente en X-Windows. En otras palabras, el X-Servidor corre sobre la máquina que tiene conectado el monitor, y el Cliente X corre sobre una gran computadora, mucho más poderosa que la anterior. La explicación de porqué las cosas parecen invertidas es que el término cliente no se aplica a la persona que utiliza el servicio de terminal, sino a la aplicación que está siendo ejecutada en el Mainframe: cada aplicación corriendo en la gran máquina es un Cliente de X-Windows, y el servidor reside en la "terminal remota".

Como X-Windows está centrado en funcionalidad de red, el escritorio remoto es ya conocido en el mundo de UNIX desde hace mucho tiempo y forma parte intrínseca del sistema operativo, por el concepto subyacente de multiusuario-multitarea. Hay que admitir que algunas interfaces gráficas tales como OSF/Motif (Open Software Foundation), datan de cuando muchos de nosotros jugábamos con las Commodore 64.

La versión de X-Windows para Linux es Xfree86, lo cual puede sonar a una redundancia, porque de por sí ya X-Windows es libre: sin ser de dominio publico, cualquiera lo puede utilizar sin pagar un centavo. Debido a esto, Linux puede tener lo que conocemos como escritorios remotos casi sin mayores problemas … Con la condición de que en ambos extremos sea Linux. Es posible colocar escritorios remotos en Windows que hagan target sobre una caja Linux, pero este software no es gratuito.

Todo este mecanismo cliente-servidor tiene un costo en rendimiento, las interfaces GNOME o KDE son masivas, y corren más procesos que su contrapartida, la GDI de Windows. En otras palabras, en Windows no se necesita un proceso servidor de interfaz gráfica, por la naturaleza de la misma, que la hace mas liviana y rápida. Es prácticamente imposible correr, entonces, una interfaz gráfica en Linux sobre un procesador de bajas prestaciones o con poca memoria disponible, ya que la ralentización excesiva de los procesos hacen que la respuesta o "sensación de usuario" en este escenario sea francamente decepcionante. En este caso, el requerimiento de hardware es por lo menos igual al de Windows.

Se ha argumentado que la interfaz gráfica de Linux se puede quitar, cosa que es cierta, y dejar corriendo el servidor en modo de carácteres, ahorrando gran cantidad de recursos. X es "enchufable", y se pude cambiar la interfaz sin resetear la computadora. Esto es debido, repetimos, a la arquitectura cliente-servidor de X. Eventualmente, la interfaz de Windows NT se puede quitar también, y lograr que el servidor corra en modo de carácteres o consola. Sin embargo, para ello deberemos tocar algunas cuestiones en el registro. Microsoft no ha colocado esta facilidad de forma directa, seguramente porque no ha querido dejar de marcar un aspecto importante: "Windows es más fácil".

En efecto, las interfaces gráficas han sido inventadas para hacer fácil lo difícil. Por esta razón, a menos que uno sea un versado en la línea de comandos, si se quita la interfaz gráfica, se quita facilidad. Y eso es justamente lo que Windows no desea. "Para usar un auto, uno no debería saber cómo funciona el ciclo Otto o Diesel, ni cómo funciona la inyección electrónica, uno simplemente lo usa." Esa sería la analogía más o menos aproximada que nos llega desde Redmond.

En nuestras pruebas, se ha encontrado que los requerimientos de funcionamiento de un servidor RedHat son por lo menos igual a los requeridos por Windows Servidor. Podrán ser iguales, pero nunca menores. La sensación de usuario en un servidor Linux decae sensiblemente si la memoria es reducida a 128 MB o menos. La interfaz grafica de Windows es más rápida que X-Windows porque carece de la sobrecarga de un sistema cliente-servidor, el pase de mensajes entre procesos es óptimo.

En las instalaciones, Linux exigía un espacio libre de 1,7 GB para a la RedHat 9.0, para dejar la instalación en una media de 1 GB ocupado. Esto no es precisamente poco espacio en disco, sobre todo si queremos investigarlo y disponemos de una partición chica para "jugar" con él.
¿Es Windows un S. O. de juguete?

Durante mucho tiempo se ha dicho que Windows es un sistema operativo de juguete, e UNIX y Linux lo son "en serio". Esto, como pronto veremos, no tiene gran asidero actualmente. Posiblemente, el hecho de que Linux está mejor posicionado como servidor que como estación de trabajo, no ha hecho sino establecer más aún esta creencia. Lo cierto es que Windows es un sistema operativo más fácil de configurar y de operar que Linux, lo cual plantea un cierto grado de desafío a la gente de IT que se enfrenta por primera vez a Linux, que ha llevado a muchos a pensar "uso linux, soy diferente, soy más capaz".

Si el utilizar un sistema operativo más "fácil" es un pecado (nótese que no estamos hablando de capacidades técnicas del S. O. sino de facilidad de uso), pues entonces los usuarios de Windows tendrán que vivir con este estigma.

En el pasado, en ciertas áreas Windows NT no podía compararse con los grandes sistemas operativos UNIX. Establecidos hace más de una década y con el suficiente know-how; compañías como The Santa Cruz Operation (SCO) tuvieron manejos de tecnologías de redes mucho antes que Windows y que otros competidores. Por ejemplo, es hoy un hecho admitido que uno de los problemas serios de Novell fue no haberle prestado suficiente atención a TCP/IP, la posibilidad de enrutamiento fue la diferencia con Windows que pudo haber jugado en algún momento en contra del venerable NOS. Cuando Novell cayó en la cuenta, NT 4.0 con su nueva interfaz tomada de Windows 95 ya había tomado suficiente momentum como para revertir la situación. Justamente, TCP-IP (Protocolo de Control de Transmisión/Protocolo de Internet) ya estaba presente en XENIX, en sus versiones de comienzos de la década de los 90's, incorporado como algo estándar. Hagamos sino este ejercicio: ¿Quiénes de nosotros en Argentina recuerdan algo de "Internet" allá por 1992? Cuando pedí la ayuda de TCP-IP en mi Xenix 386, vi por primera vez en mi vida la palabra Internet.

Windows NT 4.0 no tenía enrutamiento estático con la facilidad que tiene Windows 2000. En muchos foros se ridiculizaba a Windows NT por ésta y muchas otras razones. Evidentemente, el mercado de servidores todavía estaba dudoso para Microsoft en ese momento. Hasta que llegó Windows 2000. Muchos de nosotros percibimos que con Windows 2000 se había hecho mucho más que un restyling del sistema operativo, existía otra filosofía, otra potencia de software. Como nos confiase un insider de Microsoft en cierta oportunidad: "Con Windows 2000 sentimos que por primera vez teníamos un ganador, un software que podíamos exhibir sin sentir vergüenza". Hasta ese momento, la competencia hacía blanco en el manejo de memoria, en el límite en los 4 GB, en la falta de seguridad, en la falta de un servicio de directorio verdadero, se hacían chistes sobre LAN Manager, etc. Con Windows 2000, Microsoft elevó tanto el estándar, llegando al tope de la línea con su versión DataCenter, que dicha versión se comercializó exclusivamente por canales especiales de los OEM, uno no podía ir a una tienda minorista y ordenar un Windows Servidor versión DataCenter.

Linux arrancó con el know-how prestado, en cierta medida. Ya incorporaba todo el acervo y filosofía de UNIX, lo cual lo posicionó, naturalmente, como un candidato para los servidores.

Sin embargo, con Windows 2000 llegaron nuevos vientos. Y con Windows Servidor 2003 se consolidó la opción seria para servidores empresariales, haciendo hincapié en la seguridad. Por ejemplo, durante mucho tiempo se argumentó, no sin razón, que los huecos de seguridad a causa del Internet Explorer eran excesivos. La solución a éste y otros reclamos fue colocar las restricciones en el programa mismo del IE. En efecto, la configuración de seguridad mejorada de IE que viene con Windows Servidor 2003 está al nivel de las bibliotecas de enlaces dinámicos DLL. Cuando uno decide quitarla o colocarla, es una DLL la que se cambia, no una marca o flag en el registro. Como Windows 2003 (así como Windows 2000) posee el mecanismo de self-healing, esto es, reemplaza las DLL criticas cuyo checksum haya cambiado, pidiendo al operador que provea el CD-ROM con las versiones originales, se hace muy difícil alterar dicha funcionalidad manipulando flags solamente. Habría que interceptar todo el mecanismo de control de claves digitales de las DLL que son críticas, y eso es mucho más complicado.

La mayoría de las versiones libres de Linux no posee dichas facilidades. Cuando un archivo del sistema operativo se arruina por algún motivo, generalmente se debe proceder a una reparación explícita del mismo.
¿Desde Windows no se puede arrancar Linux?

Mucho se ha dicho que sólo Linux puede proveer arranque dual a través de su conocido LILO (Linux Loader). Lo que poca gente sabe es que el cargador de NT, NTLDR (NT Loader), es el equivalente al LILO en funcionalidad completa. Con NTLDR, es posible arrancar Windows y también otras particiones de Linux que residan en otra computadora. Lo único que Microsoft no ha hecho es explicitar el mecanismo, ya que seguramente no existe interés en ello. Pero no es información prohibida, todo lo contrario.

Para que el arranque dual exista, es necesario que primero se cargue en memoria el NTLDR. Luego, éste lee de BOOT.INI lo que el usuario puede arrancar, y exhibe un menú de opciones. Si se elige una partición Linux, el NTLDR cargará en memoria los primeros 512 bytes de la partición desconocida, pero tomándolo de la partición de arranque NTFS que es la visible para él (porque el filesystem de UNIX difiere sustancialmente en forma de NTFS), luego transferirá control a esos 512 bytes y el resto es historia. Como vemos, NTLDR también fue concebido para arrancar múltiples sistemas operativos. NTLDR solamente puede ver archivos en su propio formato de archivo (FAT, FAT32, NTFS), y es necesario transferir en forma de un archivo binario (.BIN) el primer medio kilobyte de la partición desconocida, para que NTLDR le pueda transferir control, para eso existen utilidades de terceros.

Por lo tanto, no es cierto que desde Windows no se pueda arrancar Linux. Creo que Microsoft no tiene interés en tal cosa, pero ha preparado NTLDR para que quien quiera hacerlo lo pueda hacer, y mantener a Windows como arranque primario.
¿Linux no tiene virus y tiene más seguridad?

Se suele argumentar también que la cantidad de virus que existen para Windows es mucho mayor que los que existen para otros sistemas operativos. Si nos detenemos a pensar, es evidente que esto sucede en primer término porque la base instalada de Windows es enorme. Es la ley de los grandes números. No obstante, para ser ecuánimes, debe aceptarse al menos que la instalación de servidores NT y 2000 dejaban al sistema operativo funcionando con todos los servicios críticos levantados, listos para ser atacados por gusanos y troyanos y toda clase de engendros digitales que pululan por la Red.

Microsoft ha reconocido esto, tanto tácita como explícitamente, la prueba de ello es Windows 2003 Servidor, que se instala con servicios mínimos, y exige al administrador terminar la instalación, dándole la oportunidad inestimable de instalar sólo aquellos módulos que realmente necesita.

Windows 2003 es una versión que ha sido liberada con cambios hechos en base a los continuos reclamos de sus Clientes, y esto es una posición remarcable. Pregúntese si los Clientes de Solaris o de AIX tienen tanta injerencia sobre el producto que usan como lo tuvieron los usuarios de Windows, y tendremos un panorama más apegado de la realidad.

En cuanto a la seguridad, Windows 2003 incorpora una serie de mecanismos muy robustos. Por ejemplo, para disminuir las probabilidades de accesos ilegales desde afuera, la familia 2003 servidor puede "marcar" todos los paquetes de TCP/IP que estén en su propio dominio de colisiones (esto es, en el mismo segmento físico de la LAN) con una clave dispersa (hash). Luego, si se desea, se puede pedir que se rechacen los paquetes que carezcan de ese identificador.

También con Windows 2000 ha aparecido Kerberos como una forma de autenticación por defecto (anteriormente era LAN Manager la encargada), y se da soporte a IPSec, etc. Cada uno de estos sistemas da seguridad en niveles distintos del tráfico de la red. Algunos lo hacen a nivel del paquete de datos TCP, mientras que otros lo hacen a nivel de la aplicación. El soporte de red privada virtual VPN también está presente desde NT 4.0, aunque recordemos que el sólo hecho de entrar a una red por VPN no garantiza el total acceso a los recursos de la misma, porque además se deben tener las credenciales necesarias para ello.

En este sentido, a la fecha que se escribe este artículo, el sistema operativo Windows es tan robusto como sus contrapartes de fuente abierta. Por supuesto que no tiene el récord operacional de seguridad número 1 del mundo, pero esta posición tampoco le pertenece a Linux, sino a una versión académica de UNIX: BSD. Disponible como FreeBSD y OpenBSD, el sistema operativo de la Universidad de Berkeley es un UNIX "de verdad", no es un clon como el Linux. Construido a partir de la seguridad, con una visión centrada en la misma, su arquitectura sumamente robusta le permite exhibir un récord operacional casi perfecto. Para entornos de alta criticidad, OpenBSD es una opción mucho más sensata que Linux. Sin embargo, este producto es aún más amateur que Linux, y su futuro está seriamente comprometido debido principalmente a la falta de ingresos por ventas, ya que el S. O. es totalmente libre, esto está explícitamente indicado en la homepage de FreeBSD.

En esto también no tenemos que perder de vista que la base instalada es determinante, existe una posibilidad mayor de contagio entre una comunidad de potenciales víctimas que es más grande, porque la velocidad de transmisión del contagio es geométricamente proporcional al número de usuarios conectados, y Windows es abrumadoramente más utilizado como estación de trabajo que Linux.
¿El manejo de la seguridad ante amenazas es mejor en Linux?

El sistema operativo Windows es ciertamente complejo. La gran base instalada hace de él un blanco predilecto de los hackers, y éstos han encontrado gran cantidad de "huecos", desde buffers overflows hasta aspectos de la impersonalización que utilizan ciertas cuentas de Windows para correr servicios esenciales, que se explotan para causar daño de diverso tipo.

Tengamos en cuenta estos aspectos respecto de las amenazas:

* El tema de seguridad no es trivial, ni es de solución mágica.
* El administrador de la red siempre lleva las de perder: basta que un hacker tenga un (1) sólo triunfo, para que la empresa tenga algún grado de problemas. En otras palabras: el administrador de la red no puede "no perder" nunca.
* La empresa siempre está a la defensiva. Los hackers tienen todo el tiempo del mundo, y recursos ilimitados para estudiar sin apuro las debilidades del sistema operativo.
* La respuesta que soluciona los problemas casi siempre llega después de que algún número no determinado de servidores ha sufrido algún tipo de ataque exitoso.
* En cierto modo, si bien se puede minimizar en gran parte preventivamente, determinados problemas solo se solucionan de forma correctiva, sobre todo los gusanos y troyanos.

Microsoft, siendo conciente de estos aspectos, y ante el cúmulo de problemas debido a la base instalada de Windows, optó por reforzar significativamente los mecanismos de entrega de los "remedios" para esta "enfermedad" .La respuesta vino en la forma de un gran impulso para su sitio Web de Windows Update, para el boletín de seguridad, y por el mantenimiento de una gran base de conocimientos de acceso libre y gratuito. Es muy probable que este conjunto de páginas sea el más grande y el más mantenido a escala global.

En nuestro entender, lo ha logrado: el soporte está disponible para el sistema operativo Windows con un cúmulo de información, de artículos y erratas con soluciones que se han ido acumulando con el pasar de los años, concentrados en un solo punto.

Windows Update, al mismo tiempo, ha alcanzado tal grado de sofisticación que Microsoft permite que aquellos clientes que sean grandes empresas puedan tener su propio "servidor de parches" interno, conceptualmente lo podemos ver como si el sitio de Windows Update se replicaría en un punto de la red local de la empresa, facilitando la administración de los parches y actualizaciones.

Hasta el momento, los defensores de Linux deben admitir honestamente que tal cosa no existe ni remotamente para los sistemas operativos de fuente abierta.
¿Linux administra mejor las redes?

Esto es cierto en algún grado: Windows puede hacer lo mismo que Linux, pero necesita de otro paquete que no se incluye en el sistema operativo per se.

La parte de administración muy avanzada de tráfico IP no está incluida en el producto Windows, sino en el Internet Security and Acceleration (ISA) Server. En principio, este tipo de producto solamente sería indicado en entornos donde se desea restringir el ancho de banda por IP, se desee una robusta configuración de seguridad, o se desee tener un Proxy de prestaciones importantes, entre otras cosas. En este aspecto, las versiones de servidores de Linux tienen más oferta que Windows, ya que integran en la distribución normal del S. O. Linux ciertos servicios encontrados en el ISA servidor. Nótese que los mejores servicios de este tipo, sin embargo, no pertenecen a Linux, sino a BSD.

Por ejemplo, citemos el muro cortafuegos o firewall. Existen básicamente dos tipos de firewall: los primeros se basan en examinar la cabecera del paquete de información de red solamente y determinar si lo deja pasar o no en función de conocer el par "origen-destino". Los segundos examinan el contenido completo del paquete de información (stateful inspection, término acuñado en 1993), para determinar si lo permite pasar o no. En este segundo caso, el manejo debe ser mucho más complejo que en el primero, y obviamente la carga de procesamiento es más significativa. Generalmente, los firewalls importantes como el ISA (Internet Security and Acceleration, antes Proxy Server) son del segundo tipo, mientras que los primeros son facilidades que suelen incluirse sin cargo, tal como el ICF (Internet Connection Firewall) de Windows Servidor 2003.

En Linux encontraremos una amplia oferta de firewalls -de ambos tipos- y enrutadores de fuente abierta, cuya eficacia está altamente comprobada. En este caso, la ventaja aparente de Linux es que existen distribuciones que contienen el kernel más el enrutador y firewall, todo en un solo disquete de 1,44 MB. Sin embargo, para implementar esto uno debe conocer bastante de lo que se está haciendo, y el número de usuarios que se verían favorecidos por esto es marginal, la mayor ganancia la verían gente ya versada en IT.

De todos modos, deberemos conceder algunos puntos a favor en este aspecto a Linux, y mas notoriamente, a ciertas versiones del Unix BSD.
Linux es mejor porque hay más programadores

En general, la comunidad de Linux hizo siempre hincapié en que los productos de fuente abierta son mejores en calidad que los productos comerciales, por la razón de que hay muchos testeadores del producto, y hay muchos mas recursos humanos de programación que para Windows.

Pero hagamos un poco de retrospectiva. El primer sistema operativo con interfaz gráfica para computadora personal fue la conocida LISA (Local-Integrated Software Architecture), de Apple (esto fue mucho antes que X-Windows). Luego, ésta devino en la MacIntosh, que aún subsiste en nuestros días, y para muchos sigue siendo la quintaesencia de la interfaz gráfica. Apple afirmó que se necesitaron mas de doscientos años-hombre para programar el sistema operativo, esto es, trabajando continuamente las 24 hs. del día, un programador hubiese estado sentado delante de su consola unos dos siglos y pico. Asimismo, los memoriosos recordarán que tanta potencia de cálculo solamente pudo efectivizarse con el procesador MC68000 de Motorola, primera implementación de un chip de 32 bits para consumo comercial masivo.

Suponiendo ahora que Linux tenga el doble de complejidad que la Mac (en realidad, es mucho más complejo), si hacemos unos números nos daremos cuenta que para desarrollar el sistema operativo y mantenerlo se debe tener una cantidad muy grande de desarrolladores, trabajando de una manera descentralizada esto se complica bastante.

Suponiendo también que esto realmente sea así, también es cierto de lado de Windows: existe un número de programadores del cual no podemos bajar para mantener y desarrollar el producto del calibre del S.O. Servidor Windows. El número de programadores de team que desarrolla este tipo de productos debe ser necesariamente importante.

Microsoft siempre ha sido un tanto reacio a comentar el número de programadores que dispone cada grupo. Lo curioso es que del lado de Linux tampoco se ha especificado mucho al respecto, simplemente se ha afirmado que "es mayor que Windows".

No hay bases firmes para decidir esto. Pero suponiendo que las hubiese, la gran diferencia es que en Microsoft los programadores trabajan por un sueldo (además del aspecto de realización personal, etc.) y tienen un director, quien a su vez reporta a otra persona de nivel superior, etc. Es decir, existe una escala de responsabilidades bien definida. En los programadores de fuente abierta, dispersos por todo el globo, tan cosa no está tan bien definida, a menos que sea un canal establecido de distribución, pero en tal caso, el modelo es ciertamente parecido al de Microsoft: con los canales de distribución tendremos que pagar.

Sin embargo, podemos sincerarnos al decir que en cierta forma Microsoft ha reconocido la importancia de la comunidad que usa sus productos, sobre todo la de desarrolladores e infraestuctura, y los programas de beta y facilidades para procesar los feedbacks de los testeadores tienen un lugar importante en la estrategia de la compañía. Visual FoxPro 9.0 por ejemplo, está en gran medida construida sobre los deseos y feedbacks de mucha gente nucleada en comunidades. La gran diferencia es que el control del producto está centralizado, y es Microsoft quien tiene la última palabra. El tiempo dirá si este mecanismo dio sus frutos o no.
Linux es mucho más estable que Windows

Desafortunadamente para los entusiastas de Linux, tengo que decir que esto no es tan cierto, por lo menos en mi experiencia. Yo mismo he podido colgar a un Linux 7.x con una PostGRESQL 7.0, por el sólo hecho de navegar un sitio local con el Mozilla (el navegador de Linux, equivalente al Internet Explorer).

Las colgadas de Linux son más espectaculares que las de Windows, la máquina queda totalmente congelada. También existen las fallas de violación de segmento, equivalente de la pesadilla C0000005 de Windows.

Para entender esto más en profundidad, diremos que el sistema operativo NT puede ser visualizado como una serie de anillos, correspondiendo el anillo-cero al micronúcleo o la parte más cercana al mismo. Por cuestiones de velocidad, en NT 4.0 se ha permitido que determinados subsistemas tales como el de video pueda "hablar" directamente con el kernel, a fin de obtener mayor velocidad evitando el pase de mensajes entre anillos. Recordemos que el NT 3.5 tenía una "virtualización total de hardware", incluyendo el subsistema de video. Esta estrategia le costó a Microsoft la pérdida de la clasificación de seguridad Cx que ostentaba el NT 3.5x dada por el gobierno norteamericano, pero a cambio logró velocidad. Sin embargo, un driver mal escrito podía arruinar el sistema entero, al corromper los segmentos de memoria del kernel, justamente eso es lo que sucedía a veces con NT y eventualmente 2000.

De ahí la idea de certificar los drivers, las alertas (warnings) de drivers no firmados digitalmente, etc. Pero lo que buscaba Microsoft era velocidad en el video, y evidentemente lo ha conseguido con sus DirectX, etc. Básicamente, el video mueve grandes cantidades de información, y la velocidad en los juegos o en aplicaciones de gráficos intensivos requiere el menor camino hacia y desde el kernel.(2)

Este concepto también existe en Linux. Algunos dispositivos que se adicionan al equipo exigen una recompilación del kernel, dando indicios claros de que Linux tampoco tiene la clasificación C3 de seguridad y estabilidad (algunas versiones comerciales de UNIX si la tienen). En la 7.0 el cambiar la resolución de video en Linux exigía toda una operación complicada, que requería el reinicio de la computadora. Con las nuevas versiones esto ha ido cambiando paulatinamente, pero no ha alcanzado la facilidad que tiene Windows.

Los defensores de Linux dicen que si los eventos modales se congelan, se podría "matar" el servidor X para retomar el control del sistema. Pero en mi caso, no hubo forma de retomar el control, ya que el procesamiento de mensajes modales también se había interrumpido (el puntero del ratón estaba congelado). No hubo forma de recuperarlo sino con un reinicio en frío (con la llave de encendido del equipo).

La versión RedHat 9.0 ha tenido muchísimos contratiempos en nuestras pruebas, principalmente relacionados con drivers de video. Se ha tenido que reinstalar el sistema operativo, ya que luego de instalar la base de datos el sistema quedaba inoperable. La solución, después de reinstalar el S. O. 3 veces seguidas, fue bajar a la versión RedHat 8.0, la cual funcionó correctamente.

Por lo tanto, si Windows se "cuelga", Linux también lo hace. Ninguno de los dos es perfecto. Pero si quieren una métrica, desde Junio de 2003 que no he podido colgar por software a Windows Servidor 2003, y lo hemos exigido seriamente. Más sobre el particular al final de esta nota.
¿Linux es más barato como servidor?

Eso depende de qué queramos servir. Reseñaré a continuación brevemente nuestra experiencia:

Como servidor de bases de datos
Los servidores de bases de datos están divididos en dos grandes grupos: los que son libres, y los que son pagos.

RDBMS que son libres, las más utilizadas son:

* MySQL: La primera ha sido concebida para servir datos, mayormente de sólo lectura, en sitios Web. Se destaca por su gran velocidad de recuperación de datos, y no tanto para carga transaccional. No soporta subconsultas ni procedimientos almacenados.
* PostGRESQL: Un interesante proyecto de Berkeley, es una base que evidencia cierto tipo de investigación avanzada en RDBMS. Bastante más poderosa que MySQL, soporta subconsultas y procedimientos almacenados, y tipos de datos complejos como estructuras geométricas espaciales, datos del tipo "direcciones IP" y matrices en una sola celda de una tabla. Sin embargo, carece de potencia en replicación, distribución, OLAP, warehousing, etc., temas que son de amplio dominio de las RDBMS comerciales. No tiene toda la documentación completamente traducida. Tampoco tiene servicios avanzados de desfragmentación ni reordenado, y en cierto modo se parece a Visual FoxPro en el manejo de las tablas y los índices, se percibe como una base de datos de escritorio a la que le han colocado una interfaz cliente-servidor.

Si tuviésemos que elegir entre las dos, la segunda es una opción mucho más adecuada para un desarrollador, además de tener ciertas capacidades inquietantes como almacenar una matriz en una sola celda de una tabla (¿Eso no viola la primera forma normal de las bases de datos?)

RDBMS comerciales:

Aquí tenemos la oferta de grandes jugadores como Oracle e IBM. Sin embargo, el precio de estas RDBMS es estratosférico, debido la forma de licenciamiento. Por ejemplo, IBM vende su DB2 "por procesador". Uno compra una DB2 para un (1) procesador Intel Compatible. Ahora bien, la cantidad de usuarios que puede atender un (1) Pentium IV de 3 GHz con 4 GB de RAM y disco UW-SCSI-3 de 320 MB/seg. es bastante importante. Por lo tanto, IBM cobra esas potenciales licencias, uno debe pagar por esa potencia latente, aunque no la use. Adicionalmente, en la caja vienen varias decenas de CD-ROMs con versiones de la RDBMS para casi todos los sistemas operativos que corren en ese procesador: Solaris, HP-UX, AIX, Linux, etc. Evidentemente, uno también está pagando ese desarrollo, aunque no lo tengamos pensado implementar en Solaris o HP-UX, en el costo está incluido tal característica. Si uno posee un equipo multiprocesador, deberá comprar la versión para N procesadores Intel Compatibles, etc. Lo mismo sucede con la documentación: se entregan copias de documentación en pocos idiomas principales, y existen otras -la mayoría- para descarga desde el sitio Web. Todo esto tiene sin duda un costo adicional, lo que podemos entender si pensamos que ambos proveedores tienen una fuerte presencia en el mundo del mainframe, donde las cosas son diametralmente opuestas al mundo de las microcomputadoras.

¿Cómo hace IBM para no morir en el intento de programar las IDE de administración y demás de su DB2 en sistemas operativos tan disímiles? La respuesta es previsible: las ha programado en Java. Por lo tanto, desarrolla una sola interfaz en Java, y la "publica" en todos los CD-ROM de distribución.

Esto le facilita enormemente las cosas y le asegura homogeneidad en la interfaz entre plataformas, pero a cambio de un potencial conflicto: si la máquina virtual tiene algún problema, no se podrá administrar correctamente ciertas cosas del RDBMS. Eso es justamente lo que nos pasó, tanto con DB2 como con Oracle: las máquinas virtuales tenían ciertas clases que no habían sido instaladas completamente, y no había interfaces graficas para administrarlas, sólo línea de comandos en interfaz de carácteres. Algunas bibliotecas de clases de Java se distribuyen en forma comprimida, y para su utilización deben descompactarse, por algún motivo esto no se hizo correctamente, y las interfaces gráficas no funcionaron. Desafortunadamente, no hay soporte explicito de la Java VM en la documentación de IBM o de Oracle, hay que remitirse al responsable de ese componente, que es Sun Microsystems. Tras dos semanas de visitar los foros, se halló el problema.

Con Microsoft, uno siempre se enoja o se complace con una sola compañía, que controla el 100% del producto. En ciertos momentos, esto puede ser muy ventajoso, porque Microsoft ha hecho ingentes esfuerzos en tener el mejor sitio de soporte al usuario. No sabemos si actualmente es el mejor o no, pero ciertamente es fácil de usar y con cantidades masivas de conocimiento.

Otro punto un tanto dudoso es el enorme consumo de memoria y procesador de la VM cuya imagen es JREW.EXE (Java Runtime Environment for Windows) cuando ésta corre en Windows, ya que tiende a consumir casi toda la memoria disponible. En nuestras pruebas, en un Athlon de 700 MHz, 256 MB de RAM, Windows 2000 Servidor, el JREW consumía 240 MB de RAM.

Lo curioso es que en Linux esto también sucede: la máquina virtual JRE (sin la W, obvio) consume tantos recursos de memoria como su prima de Windows. En nuestras pruebas en Linux consumió 242 MB.

IBM y Oracle han hecho una fuerte apuesta a Linux, para intentar interesar al medio empresarial de un target medio hacia arriba. Expresamente han indicado que el target de "bajo nivel" en RDBMS se lo dejan a Microsoft, ya sea que esto es bueno o malo, lo cierto es que han desaparecido de nuestra vista las ofertas de la DB2 para grupos de trabajo de 10 personas, la cual tenía en su momento un precio bastante contenido de unos USD 1.000,00 (un mil dólares estadounidenses).

En RDBMS comerciales, Microsoft es el campeón del licenciamiento, ya que es la única base de datos de corriente principal que tiene licenciamiento por asiento y por servidor a un precio accesible. Para una Pyme, es muy difícil para un profesional en IT recomendar otra cosa que no sea SQL Server, por su inmejorable relación precio-prestación.

Por otro lado, para una gran corporación internacional con presencia en 5 continentes posiblemente las soluciones en bases de datos pasen por el mundo del mainframe, donde todavía las computadoras que conocemos en nuestra vida diaria no tienen la potencia necesaria. Por ejemplo, un mainframe de rango inferior puede atender en horas pico unas 300 transacciones por segundo en un sistema de tarjetas de crédito montada aquí en Argentina, con una gran RDBMS que ya se ofrece integrada al sistema operativo. Este rendimiento (tasa sostenida) son difícilmente alcanzables por las microcomputadoras. En el mundo mainframe de corriente principal, la mayoría de los procesadores no son producidos por Intel, por lo tanto, no existe software Windows que funcione sin emulación o sin una tarjeta hija (daughtercard) con procesador "i386 compatible".

Si embargo, este cambio está a la vuelta de la esquina: los procesadores de 64 bits están por llegar gradualmente, elevando el alcance del software Intel-compatible, es decir, dando oportunidad a SQL Servidor a subirse a la corporación multinacional por vez primera en su historia. Apuesto sin dudar a que la gente de Redmond está a full con Windows y SQL Servidor de 64 bits.
Herramientas de Desarrollo

He aquí, desde mi punto de vista, la gran asignatura pendiente de Linux.

La oferta de IDE y herramientas de desarrollo palidece en cantidad respecto a la oferta de Windows, pero para ser ecuánimes, tenemos que decir que algunos productos pagos para Linux pueden funcionar para una gran empresa, no para una pyme. Pero veamos más en detalle las implicancias de esto:

Desarrollo de Páginas Web:
En nuestras pruebas, hemos constatado que para el desarrollo de páginas Web con acceso a datos, lo único libre y viable por facilidad de configuración y cantidad de servicios ofrecidos es PHP (Hypertext Preprocessor), que no es otra cosa que scripting del lado del servidor, similar al ASP. La conectividad de bases de datos se da a través de bibliotecas específicas con las antemencionadas free RDBMS, y para las otras pueden existir drivers JDBC (que es una evolución de ODBC, escrito en Java y con orientación a objetos).

El servidor de páginas de rigor es Apache, el cual, hay que admitir, es estable y funciona sin mayores problemas, incluso existen versiones que son ISAPI compatibles y corren en Windows. Apache, sin embargo, tiene su fuerte bastión en el mundo Linux, y puede usarse con otros lenguajes tales como Perl, Phyton, etc. alguno de los cuales son equivalentes, en cierto modo, al CGI de Windows.

Desarrollo de Clientes Ricos (o Pesados o Inteligentes):
Aquí existen pocas opciones potables, mayormente orientadas a Java. La más notable que sea no-Java es KyLix de Borland, una portación de Delphi a Linux. No tenemos noticias de su funcionamiento, aunque se descarta un buen rendimiento debido al compilador, un nicho donde Borland ha permanecido luego de relegar otras posiciones(3) . El precio de Kylix, sin embargo, excede los USD 3.000,00 para la versión completa (el equivalente a una versión Entreprise de Microsoft).

Java, nacida originalmente para utilizarse en heladeras y electrodomésticos, ha evolucionado para posicionarse como la única alternativa seria a la iniciativa .NET de Microsoft, esto lo reconocen las mayores consultoras del mundo en IT.

De nuevo, Oracle e IBM están impulsando fuertemente a Java. Ambas compañías, acompañados de una miríada de competidores de Microsoft, han planteado estándares de Java, dividiéndolo en tres. El mayor de todos es el llamado J2EE (Java Enterprise Edition). Rápidamente lo podríamos definir como un conjunto de clases de Java, destinado a brindar soluciones empresariales completas de alto rango y escalabilidad. Es una base tecnológica muy amplia donde se pueden construir soluciones informáticas de casi cualquier porte.

Curiosamente, .NET encaja en la misma definición. J2EE es la contra cara de .NET. Detrás de J2EE se alinea casi todas las grandes compañías que compiten con Microsoft. Pero si uno examina de cerca ambos estándares, llega inmediatamente a la conclusión que tiene una extraordinaria similitud, la esencia que persiguen es la misma. Necesitaríamos veinte artículos como este para una comparación en profundidad, debido a la cantidad masiva de clases de ambos (unas 5.000 de cada lado). Algunos conceptos de ambos frameworks son idénticos, como el de reflection, ya que son comunes a la tecnología de objetos, no a la implementación de una determinada marca.

Ahora bien, si persiguen lo mismo, ¿la implementación a la que han llegado es la misma? Aquí creo que respuesta es NO. Existen algunas diferencias importantes en las implementaciones reales de ambos mundos.

Hemos comprobado personalmente que para sacar el mayor potencial a J2EE se necesita una IDE muy poderosa, del mismo modo que para explotar a .NET a fondo necesitamos Visual Studio. Esa IDE existe, y se llama Websphere Suite, una complejísima IDE hecha totalmente en Java.

La Websphere es una implementación comercial de Eclipse, que a su vez es una IDE de fuente abierta para J2EE. Sin embargo, en nuestras pruebas, Eclipse para Linux ha demostrado ser altamente inestable. Nuestro equipo de pruebas no pudo avanzar mucho, ya que ciertas opciones en algunos iconos colgaban la IDE, perdiendo el trabajo realizado.

Se ha probado también Websphere para Windows, y ha resultado ser mucho más estable que Eclipse, a pesar de que la versión utilizada era una "early availability", (algo así como un "release candidate"). Evidentemente, las versiones comerciales son más estables que las open source, según nuestra experiencia Eclipse no ha servido mucho más que para un "technology showcase", una vidriera para mostrar su potencial, pero no para realizar un gran sistema de información de implementación real, ya que verificamos que el número de bugs es muy significativo.

Existen, sin embargo, algunas cosas que no debemos perder de vista. La tecnología Java no deja de ser interesante, y es objeto de mucho estudio en todo el mundo. La tecnología .NET intenta superarla, por supuesto. Pero todavía, en algunas áreas, se nota cierta madurez que está en J2EE y no en .NET. Por ejemplo, el mapeo de objetos a tablas relacionales (object-relational mapping) está contemplado en J2EE, y el Studio Webshpere es capaz de inferir la estructura de las tablas relacionales conociendo el diagrama UML de las clases, en tiempo de diseño, aplicando más de una forma distinta de mapeo a voluntad del programador - como una característica estándar. En efecto, la cantidad de formas en que podemos mapear un objeto (es decir, sus propiedades) a una o más tablas es limitada y éstas son conocidas. IBM sólo sistematizó este conocimiento en su IDE.

Microsoft en su .NET 2.0 intentará nivelar las cosas con su nuevo ObjectSpaces, que descartamos que tendrá igual funcionalidad, sobre todo operando sobre SQL Servidor (destaquemos que el producto de IBM funciona según lo descrito solamente si el back-end es DB2).

Se percibe que ambas tecnologías maduran rápidamente. Pero costo por costo, WebSphere Suite en su versión máxima es significativamente más caro que .NET Enterprise Architect.

También existen otras diferencias fundamentales en el ámbito de utilización. Las compañías como IBM que comercializan líneas de mainframes, están apostando a que Java pueda correr sobre mainframes, con las ventajas de este tipo de computadoras, que puede en algunos casos exceder enormemente el precio de un servidor como los que estamos acostumbrados a ver.

Uno diría "¿Java en un mainframe?". Sin embargo, sus defensores dicen que la idea no carece de sentido. En un mainframe, por ejemplo, un AS-400, existe la posibilidad de virtualizar el procesador, es decir, "clonarlo" para hacer ver a los procesos como que más de un procesador está instalado en la computadora. Lo interesante es que esta virtualización se hace por hardware, no por software: el software corriendo en el mainframe "ve" como que el procesador puede "replicarse" a si mismo hasta una cantidad de 15 veces, habilitando multiprocesamiento. Incluso cada una de estas instancias puede correr un sistema operativo distinto(4).

Estos conceptos, que nos parecen prima facie tan raros, recientemente han desembarcado en el mundo de las microcomputadoras: el Intel P4 con Hyperthreading hace algo muy parecido.

Por lo tanto, sumando cantidad de herramientas, y relación precio/prestación, Windows en este punto gana muchos enteros a su favor.
¿Linux es un sistema operativo en tiempo real?

Definitivamente no. Pero tampoco lo es Windows. Al menos, no el Windows que tenemos en nuestro escritorio. Veamos que es un sistema operativo en tiempo real (RTOS): básicamente, es un S.O. que tiene como característica principal el asegurar en todo momento un tiempo de respuesta determinado ante una entrada al sistema.

Una breve intro primero: convengamos que un evento puede ser visto como un mensaje generado por el sistema. Uno hace un clic en la pantalla, el sistema operativo genera un mensaje asociado a una interrupción, etc. El tiempo en que se procesa esta petición y que uno obtiene lo que desea puede ser muy variable.

Intuitivamente, podemos pensar que depende de la cantidad de carga de procesamiento del sistema completo en ese momento, y estaremos en lo cierto si pensamos así.

Existen sistemas RTOS de larga trayectoria como el QNX, que corre sobre una PC común. Luego, podemos inferir que la característica de "tiempo real" la da el software, ya que el hardware sigue siendo el de una PC regular.

La idea con los RTOS es, entonces, que se asegure un tiempo de respuesta independientemente de la cantidad de procesos que esté corriendo el S. O. Para que eso suceda, hay que inter-construir un sistema de mensajería especial en el sistema operativo -mensajería IPC (interprocess communication)- que sea rápida, y cuyos mensajes casi no consuman ciclos de reloj en su preparación, envío, recepción, etc. Normalmente esto se logra estableciendo un protocolo de comunicación sencillo, con mensajes de longitud uniforme. Y en los procesos que corren, lo esencial sería que no haya diferenciación entre procesos de usuario y procesos de sistema.

Justamente todo lo contrario de lo que ocurre en Windows y en Linux.

Por lo tanto, Windows y Linux son sistemas operativos no determinísticos, es decir, no podemos asegurar el tiempo de respuesta completo (roundtrip) en el 100% del tiempo de operación del sistema en su conjunto. En el control de un proceso, por ejemplo, se requiere que desde que se efectúa una entrada, la salida o respuesta ante esa entrada se de siempre, en todo momento y bajo toda condición, dentro de un tiempo determinado(5) .

Otro requerimiento interesante de lograr es que el sistema operativo retenga siempre el control, en otras palabras, el requerimiento es que no se "cuelgue", que no tenga system crashes. Cosas como el kernel panic de Linux son inviables en un RTOS. Y me consta que Linux se cuelga (referirse mas arriba al apartado correspondiente).

Sin embargo, existe una plataforma Windows que tiene características de tiempo real: la aparentemente humilde Pocket PC tiene su sistema operativo que puede ser utilizado como RTOS. Esto es, entre otras cosas, debido a su modularidad excelente(6) y a la sencillez del mismo favorece la facilidad de la mensajería IPC, administración de memoria y de recursos de hardware. El sistema operativo de las Pocket PC tiene una interfaz derivada del Windows 95, pero ahí acaba su parecido con el Windows de escritorio. Internamente, es totalmente un nuevo software.

En la plataforma Linux (sería la corriente liderada por la Palm) no hay competencia cierta respecto a este punto en particular. En cambio, algunas Pocket PCs se han probado como controller de procesos, cosa que no sería viable si no tuviésemos un verdadero RTOS.
Conclusiones de los alumnos

Al cabo de haber revisado varias soluciones hechas por nuestros alumnos, conversamos con ellos a fin de obtener una tendencia, alguna métrica que nos indique si existe una respuesta en la cuestión Windows vs. Linux. La población era de 40 alumnos. Transcribimos algunos puntos importantes de la expresión de los propios alumnos, recogidas en Diciembre de 2003:

A. ¿Qué plataforma le pareció más fácil?
100% dijo: Windows, la facilidad conque hace las cosas es su mejor punto. En Linux muchas cosas se deben hacer en línea de comandos, hay que aprenderse de memoria los switches. Tuvimos que instalar dos veces el sistema operativo, porque no perdona errores. El tema de los drivers para placas raras es una pesadilla. Las colgadas de Linux son peores que las de Windows. Alguna documentación no existe en castellano.

B. Si usted fuese contratado por una Pyme para hacer un sistema informático de gestión general, ¿Qué plataforma elegiría y porqué?
90% dijo: Windows. Porque es más estable. La version Redhat 9.0 es la peor que jamás haya visto, por el numero de bugs, tuvimos que bajar a la 8.0 que es más estable, o cambiar a SUSE (otra distribución). El software de Windows es mejor porque es comercial, al haber dinero de por medio, el producto tiene que salir a la calle aceptablemente bien. El software de Linux no es de nadie, justamente eso es lo que atenta contra su calidad, no hay nadie que lleve el control de las cosas, los canales de distribución tienen versiones pagas que son mas estables, pero son mas caras que Windows (la Redhat 9.0 multiprocesador full excede los USD 15.000). Las impresoras en Linux son otro problema si el modelo es muy nuevo, hay que usar drivers genéricos, etc.
10% dijo: Linux de lado del servidor, porque no tiene costo de inversión inicial. Los clientes los haríamos, sin embargo, en Windows, solamente el servidor en Linux. Pondría la base de datos en Linux, pero los clientes pesados los haría para Windows.

C. ¿Cómo evaluaría las herramientas de desarrollo disponibles en ambas plataformas?
80% dijo: para Windows hay mucha mas oferta para IDE de desarrollo. Para Linux, solamente Eclipse, que no anda muy bien, ya que es una versión de "early availability" (el equivalente a los Releases Candidates del mundo Windows). La que anda bien es Websphere, solamente para java, y cuesta varios miles de dólares, además es mucho mas complicada que la ide de .NET. Lo único interesante es PHP (el equivalente en Linux de ASP), que es relativamente fácil como ASP. Con Eclipse perdimos demasiado tiempo. Probamos con .NET y la IDE al principio nos atemorizó, pero la cantidad masiva de recursos en la red es impresionante. Creo que del lado de Windows está la facilidad de uso, con Windows lo imposible se hace difícil, todo lo hacen tan fácil, tan rápido (Nota de la cátedra: refiriéndose al SQL servidor y a la implementación de servidores Web y extensiones de programas). Windows es conocido, es probado, y bien configurado es seguro.
20% dijo: existen ciertas herramientas de Sun que son IDE gratuitas para Java. Solamente programaría en Linux si es en Java, sino no lo haría. Para Internet, usaría PHP del lado de Linux, aunque también es atractivo el Apache para Windows con PHP para Windows.

D. ¿Se animaría a implementar totalmente en GNU una solución informática completa? (es decir, servidor, clientes, y suite de oficina)
80% dijo: No. Sobre todo del lado de los Clientes, no existen herramientas estables, menos en la suite de oficina. Open Office está lleno de bugs, es visualmente muy linda, pero demasiado inestable. StarOffice es paga, dejó de ser gratis hace 2 años. Si Linux tiene un problema serio, no sé a quien acudir.
20% dijo: Sí, haría el intento si mi cliente me deja. El mayor desafío será enseñarles a los operadores a olvidarse de Office y utilizar otra cosa, ya que Word es muy fácil.

En marzo de 2004 hicimos las mismas preguntas, a continuación transcribimos textualmente algunas de las opiniones de un grupo que utilizó Java del lado de Windows para Cliente, y el servidor de Linux con PostGRESQL, este fue el grupo que menos favoreció a Windows, y sin embargo creo que algunas opiniones son interesantes:

"En general, los mayores problemas los encontramos del lado de Linux (es decir, haciendo un balance respecto de lo que nos hubiese costado instalar los servicios en Windows donde éste es de mejor complejidad). Puede resultar mas ventajoso en Linux por el tema de la licencia."

"Esta cátedra me pareció muy interesante ya que aprendí mucho sobre las distintas tecnologías de desarrollo que existen en el mercado ... En cuanto a mi opinión sobre la plataforma de desarrollo utilizaría Windows, ya que existe bastante ayuda, la versión XP es muy estable y amigable. También me interesó la programación en Java, por su filosofía de escribir una vez y ejecutar donde sea..Todo esto depende del cliente, ya que a lo mejor pretenda facilidad de uso (Windows) y no economía (Linux)"

"Windows proporciona mayor facilidad para la configuración de los servicios, lo que facilita su utilización, y considero que presenta menos problemas de funcionamiento, y es más conocido por los usuarios en general. Linux resulta mas difícil de configurar, por lo menos en principio, y debido a la falta de experiencia de uno ... A veces se nos presentaron problemas inesperados de dudosa resolución que no contribuyen a [recomendar] su utilización ... Resumiendo: en principio utilizaríamos Windows ..."

"Un servidor Linux es una buena alternativa si hay limitaciones financieras o si existe algún experto en el tema. Si lo financiero no es una limitación, el uso de un servidor Windows 2000 o superior nos da una mayor facilidad a la hora de configurar. Otra razón es que en ocasiones Linux no es muy estable y aparecen problemas como fallas de servicios, inestabilidad de la interfaz gráfica, etc. Para Windows existe una mayor cantidad de aplicaciones que facilitan el desarrollo y la administración"

"Si el día de mañana me propusieran el desarrollo de un sistema ... Me gustaría mucho poder montarlo sobre un servidor Linux ... Aunque al principio me pareció muy difícil ... La desventaja del comienzo queda tapada por las ventajas de seguridad y costo ... Aunque también es cierto que el medio todavía resulta extraño ... Y no cualquier Cliente va a dejar de lado Windows. Sobre Java puedo decir que no me impactó ... Me inclinaría más por un .NET."
Conclusiones finales

Ciertamente no podemos negar la importancia de Linux como opción para servidores. Empresas como IBM han apostado detrás de este S.O. ingentes recursos para ganar terreno en la arena de IT. Evidentemente caeríamos en una necedad inexplicable si negamos su presencia y gravitación en ciertas esferas de nuestra actividad.

Sin embargo, a la luz de nuestra experiencia, muchos mitos que circulan acerca de Linux son simplemente eso, mitos. Windows es una opción madura y estable para el extremo servidor, y su costo total es comparable al de Linux. Todo eso sin contar con la facilidad intrínseca de utilizar Windows. Personalmente creemos que Windows es mejor que Linux. Pero poca gente creerá esto que digo, viniendo de un MVP. Sin embargo, en este extenso artículo se volcaron muchos datos y hechos de personas que no tienen vinculación alguna con Microsoft, ni siquiera que tienen simpatía hacia MS.

Si el lector acepta esto como cierto, concluirá con nosotros que Windows es sin lugar a dudas una opción muy válida y una ganadora en el ámbito de la empresa. ¿Por qué decimos esto? Por lo que les acabo de contar en estas páginas.

(1) Muchos estudios independientes han establecido claramente que la ventaja de la gratuidad del sistema operativo se ve opacada por los costos de entrenamiento, o bien outsourcing, o bien costos por asistencia que son necesarios cuando el entorno carece de gente entrenada para administrar y operar Linux. Volver al texto.

(2) Destaquemos que Windows 2003 Server también incorpora una distinción en los drivers de impresora, los cuales, al mover gran cantidad de información, en las versiones anteriores del sistema operativo necesitaban el acceso al kernel. En Win2K3, los drivers de nivel 2 son aquellos que "hablan" directamente con el kernel, incorporando la novedad de los drivers de nivel 3 que no lo hacen. Por lo tanto, los de nivel 3 son más seguros ya que un driver fallido no tirará abajo toda el sistema operativo. Por defecto, en Win2K3 no se permite la instalación de drivers de nivel 2 (en modo de kernel) , el administrador debe hacer un cambio en las políticas de grupo para habilitar esta posibilidad. Volver al texto.

(3) Borland se ha desprendido de dos de sus productos insignia: Quattro Pro y Paradox. Particularmente pensamos que los productos antemencionados no eran malos ni mucho menos, pero el mercado decidió a favor de Office, por Excel y Access. Quattro Pro forma parte de otra suite comercializada por Novell, juntamente con WordPerfect como procesador de textos. Debido a la predominancia de Office en el mercado, todas las suites tienen compatibilidad con MS Office, en mayor o menor grado. Volver al texto.

(4) Tales posibilidades también existen en el mundo de las PCs, con VMWare o Virutal Pc de Microsoft por ejemplo, pero tengamos presente que son soluciones por software, donde el microprocesador único debe atender todos los requerimientos. Un mainframe como el mencionado, en cambio, tiene la estructura de registros del procesador, el núcleo, y otros componentes como el acceso a la memoria y periféricos preparados para soportar esta facilidad de autorreplicación directamente desde el hardware. Muchos incluso se venden con el procesador configurado para rendir sólo un 10 ó 20% del máximo posible. Cuando uno compra una actualización a algo de más prestaciones, bastará habilitar más potencia de procesador con una clave digital, un proceso que no demora más de 20 minutos y no implica cambiar nada físicamente. Volver al texto.

(5) Para tener una idea, el sistema de control de carga eléctrica del sistema del Nordeste Argentino, que controla varias provincias argentinas, opera sobre una PC regular, con un RTOS QNX y un software de control RealFlex. Cuando ocurre una entrada en un extremo del sistema, en cualquier lugar de la red eléctrica de esas provincias, el sistema debe responder al evento en no más de 3.000 milisegundos (3 seg.), si importar NINGUN factor externo o interno, ese tiempo incluye: transmisión de la entrada, decodificación, introducción a la PC, captura de señal por el software, proceso de la información, codificación, transmisión de la señal de salida al lugar de origen, y actuación (respuesta efectiva). Esa PC controla la energía que es consumida por unas cinco millones de personas y que representa una facturación de millones de dólares, por lo tanto intuimos otra característica importante: no se puede "colgar" NUNCA. Y de hecho, no lo hace. Existen pocos centros de operación en Argentina, el principal en Rosario que controla varias regiones del país, el secundario en el Chaco, que controla el Norte. Volver al texto.

(6) Los S.O. Pocket PC son adaptados para cada dispositivo en particular por los fabricantes, uno no puede ir a comprar un Windows Mobile 2003 a Microsoft, ya que el acuerdo comercial prudentemente inhibe a MS de venderlos directamente al público, solamente los OEM pueden hacerlo debido a que es absolutamente necesario preparar el SO para el hardware de cada dispositivo en particular. Volver al texto.

Carlos Alejandro Pérez es Ingeniero Electromecánico de la Universidad Tecnológica Nacional, Resistencia, Argentina. Trabaja como Desarrollador desde 1991 y está enfocado en soluciones de bases de datos con VFP y SQL Servidor, sobre redes Windows. Es Profesor desde 1993 y actualmente está al frente de cinco cátedras en la UTN: Automatización y Control Industrial, Teoría del Control, Diseño de Bases de Datos para Sistemas de Información, Desarrollo de Aplicación Cl