Número Anterior | Buscar en TidBITS | TidBITS Home Page | TidBITS-es | Siguiente número

TidBITS Logo

TidBITS-es#536/26-Jun-00

¿Qué sucedió cuando el famoso defensor del código abierto (open source) Eric Raymond se reunió con 300 intransigentes programadores Mac en la conferencia anual de desarrolladores MacHack: hubo encontronazo o llegaron al entendimiento? Esta semana también, Ton Risley cuenta su experiencia al transformar un PowerBook estropeado en un potente router y servidor Internet. Por último, el proceso antimonopolio contra Microsoft podría ir al Tribunal Supremo de los EE.UU. y además te informamos sobre qué reproductores MP3 son los más populares.

Temas:

Copyright 2000 TidBITS Electronic Publishing. Derechos reservados.
Información: <info@tidbits.com> Comentarios: <editors@tidbits.com>


Este número de TidBITS está patrocinado en parte por:


MailBITS/26-Jun-00

El caso antimonopolio contra Microsoft al Tribunal Supremo -- El Juez de Distrito Thomas Penfield Jackson - que ha presidido el juicio antimonopolio contra Microsoft - ha estado de acuerdo con la petición del Ministerio de Justicia de los EE.UU. de acogerse al Expediting Act para enviar la apelación de Microsoft directamente al Tribunal Supremo de los EE.UU., saltándose el Tribunal de Apelación. El juez Jackson ya había encontrado a Microsoft culpable de violar las leyes antimonopolio y, a principios de mes, ordenó una serie de restricciones en las prácticas comerciales de Microsoft y la partición de la compañía en dos entidades separadas. La decisión de despachar el caso directamente al Tribunal Supremo es un golpe para Microsoft, que quería continuar en el Tribunal de Apelación, que en el pasado había tenido una actitud benévola con la compañía y (en una controvertida decisión) ya había aceptado escuchar la apelación de Microsoft con un jurado de siete jueces en lugar de los tres habituales. Sin embargo, la decisión del juez Jackson tiene un resquicio de esperanza para el gigante de la informática: la orden de desmantelamiento del juez y las condiciones restrictivas sobre la compañía están suspendidas hasta que la decisión sea anulada o Microsoft agote sus apelaciones. El Tribunal Supremo debe decidir ahora si escuchará el caso - una decisión que podría llegar pronto o tardar meses - y podría todavía ceder el caso al Tribunal de Apelación. (Para más información, léete los reportajes de TidBITS sobre el tema antimonopolio de Microsoft). [GD]

<http://db.tidbits.com/getbits.acgi?tbart=05875>
<TidBITS-es-525.html>
<http://db.tidbits.com/getbits.acgi?tbart=05971>
<TidBITS-es-534.html>
<http://db.tidbits.com/getbits.acgi?tbser=1152>

Presentación de la encuesta: Vivimos para servirte -- A pesar de la falta de interés mostrada por Apple en los últimos años por esta característica, el Mac OS es capaz de funcionar como servidor de Internet de forma estable, barata y fácil de administrar para sitios con un tráfico moderado (o para usos personales, como verás mas adelante en el artículo de Ron Risley). La pregunta de esta semana, por lo tanto, es: Si utilizas tu Macintosh como servidor de Internet, ¿que servicios proporcionas?. Si llevas un montón de tiempo defendiendo los servidores de Internet basados en Mac OS, esta es tu oportunidad de convencer a los usuarios que no creen en el Mac como una plataforma viable para su uso como servidor. ¡Vota ahora mismo en nuestra página principal!. [ACE]

<http://www.tidbits.com/>

Resultados de la encuesta: Quiero mi MP3 -- Los resultados de la encuesta de la semana pasada sobre cual era tu reproductor de MP3 favorito nos han sorprendido bastante. Solo un 12 por ciento de los cerca de 900 encuestados respondieron que nunca escuchaban los MP3, y la verdad es que esperábamos que fueran bastantes mas. El mayor porcentaje de votos se repartió entre SoundJam y Audion, que acabaron empatando en un duelo muy reñido con un 30 por ciento. QuickTime Player, SoundApp y Macast ocuparon la banda media, con porcentajes entre el 5 y el 9 por ciento, quedando GrayAmp, RealPlayer, MVP, Aqueous, y QuickAmp en la zona inferior con porcentajes prácticamente testimoniales. Solo 21 personas eligieron la opción Otros, con sugerencias enviadas al Foro de Discusión de TidBITS (TidBITS Talk) tales como AppleSource MP3, MPLAY, Liquid Audio Player, y Amp Radio. Puedes ver la discusión completa con abundante información y enlaces en TidBITS Talk. [ACE]

<http://db.tidbits.com/getbits.acgi?tbpoll=45>
<http://db.tidbits.com/getbits.acgi?tlkthrd=1069>


El código abierto y el Macintosh

por Adam C. Engst <ace@tidbits.com>

Acabo de llegar de la conferencia anual para desarrolladores MacHack, donde todas las conversaciones han girado en torno al código abierto (open source), mayormente gracias a la desafiante conferencia inaugural de Eric Raymond, defensor del código abierto y presidente de la Iniciativa de Código Abierto (Open Source Initiative). La conferencia de apertura, que comenzó a la medianoche, como es tradicional, terminó cerca de las 6 de la madrugada, con Eric y un público compuesto por desarrolladores Macintosh debatiendo los méritos del código abierto en la industria del Macintosh. (Para saber más sobre MacHack, consulta "MacHack: The Ultimate Macintosh Event" en TidBITS-487).

<http://www.opensource.org/>
<http://www.tuxedo.org/~esr/>
<http://db.tidbits.com/getbits.acgi?tbart=05463>

¿Que es el código abierto? -- La idea subyacente tras el código abierto es que desarrolladores de todo el mundo, interesados en esta iniciativa, trabajen en equipo a través de Internet en proyectos de programación coordinados y mantenidos por un pequeño grupo de programadores. Los programas resultantes se distribuyen de forma gratuita con su código fuente, lo que permite a cualquier desarrollador detectar errores de programación o realizar modificaciones. Si las modificaciones se aceptan por los coordinadores, se incluyen en la siguiente versión del programa.

Este sistema proporciona a los programas de código abierto una gran fiabilidad y una respuesta muy rápida a los errores de programación y agujeros de seguridad. Añade a eso el precio (¡gratis!) y comprenderás la popularidad de iniciativas de código abierto tales como el sistema operativo Linux y los servidores Web Apache.

Aunque puede parecer que el modelo de código abierto está intrínsecamente desligado del dinero, eso no es así. Probablemente, la innovación de Bill Gates que posibilitó la creación de la industria de las aplicaciones informáticas no ha sido el MS-DOS ni el Windows, sino el concepto de que un programa informático tiene un valor intrínseco y se puede pedir dinero por él. A partir de ese momento, la industria cambió hacia a un modelo donde los programas se distribuían como un producto comercial, ganando dinero con su venta y proporcionando documentación y soporte técnico de forma gratuita. El problema, como apuntó Eric, es que este modelo de "programación comercial" genera unos ingresos fijos, mientras crea unos costes futuros prácticamente ilimitados en el campo del soporte técnico.

Ahora, volvamos al código abierto. no hay nada malo en regalar programas informáticos, pero todos necesitamos ganarnos la vida. El concepto de código abierto solo puede funcionar como un modelo comercial si se cobra por algo que no sean los programas. Puede ser la documentación, el soporte técnico, la distribución o productos secundarios como módulos o extensiones - no importa qué, hemos pasado a hablar de un modelo de servicios en lugar del modelo de programación comercial. Así es como Red Hat y otras compañías de código abierto ganan dinero, e incluso en el mundo de los fabricantes tradicionales de programas comerciales, la venta de soporte técnico, formación y documentación se ha convertido en una fuente de ingresos cada vez mas popular para esas compañías.

<http://www.redhat.com/>

El encontronazo -- En principio, la charla de Eric podría haberse dirigido a cualquier audiencia, y aunque se dieron argumentos convincentes de porqué el código abierto funciona mejor que los modelos tradicionales de desarrollo de aplicaciones informáticas, estaba claro que era la primera vez que Eric se dirigía a la comunidad de desarrolladores para Macintosh. el mayor desencuentro que se produjo, casi inmediatamente, fue debido al énfasis que hace el mundo del código abierto en una comunidad de desarrolladores trabajando en equipo, frente al enfoque del mundo Macintosh hacia el usuario final.

En el código abierto, aunque los proyectos se mantienen por un reducido número de programadores, cualquiera puede aportar su propio código. Listas de correo, sitios Web y otras formas de comunicación electrónica conectan a los programadores, que a su vez son los usuarios de los programas. Solo recientemente los programas de código abierto han comenzado a entrar en el mundo de los usuarios finales - un usuario con bastante formación técnica puede coger una copia de Linux e instalarla sin problemas, pero todavía es impensable darle a alguien sin conocimientos informáticos un Linux para que intente instalarlo.

En cambio, desde sus orígenes, el Macintosh ha sido "el ordenador para el resto de nosotros" y esa actitud es la razón fundamental de su existencia. Se supone que le puedes dar un iMac a tu abuela y no tendrá problemas para usarlo. además, el tamaño relativamente pequeño y el carácter minoritario del mercado Macintosh han generado un fuerte sentido de comunidad que ayuda a los programadores a identificarse con el "resto de nosotros". En los inicios del Macintosh, la comunicación electrónica no era lo que es ahora, por lo que los grandes grupos de usuarios fueron el medio para facilitar el contacto personal entre los maqueros. Además, el mismo hecho de que existiera un mercado - que solo ha comenzado a existir recientemente en el mundo del código abierto - también significó que eventos tales como la Macworld Expo dieran más de una oportunidad a los desarrolladores para comunicarse con el público. Por último, como quedó claro viendo las frenéticas partidas en red de Carmageddon que se mantuvieron durante la MacHack, en el mundo Macintosh, los programadores suelen ser también usuarios finales.

<http://www.interplay.com/carma/>

Esta forma de hacer las cosas, centrada en el usuario, también ayuda a explicar uno de los principales defectos de los programas basados en código abierto: la interfaz del usuario, tal y como el propio Eric admitió. Cuando todos los usuarios de un programa gozan de elevados conocimientos técnicos, una interfaz fácil de usar pierde importancia. Además, la labor, algo dictatorial, de guiar y facilitar la creación de buenas interfaces, debe ser muy constante para lograr sus objetivos. Ese es el caso de Apple, donde su énfasis en la coherencia interna de las interfaces gráficas ha tenido éxito - casi todos los programadores del Macintosh se esfuerzan mucho en la interfaz; a veces más que en el propio código. Ya que la comunidad del código abierto carece de cualquier guía para proporcionar esa "adecuada" experiencia de usuario, los programas presentan diferencias brutales en su aproximación al problema de la interfaz. Muchos de ellos, incluso, son operados mediante líneas de comandos y archivos textuales de configuración, herencia del Unix.

La estrecha conexión entre desarrolladores de programas y usuarios también generó discusiones, como cuando Eric afirmó que los programas de código cerrado son intrínsecamente poco fiables, debido a la inexistencia de un profundo proceso de revisión. Los asistentes a MacHack dijeron estar convencidos de escribir un código fiable, puesto que de no hacerlo así no sólo incurrirían en un mal servicio al usuario, sino que también provocarían costosas llamadas al soporte técnico. Pero a Eric le resultó facil contradecirles, al preguntar durante cuántos años suelen funcionar los Macs antes de que sea necesario reiniciarlos. Es difícil precisar una respuesta que refleje la realidad, pues los asistentes a MacHack probablemente escriban un código mejor que la media. Es más, muchos errores que aparentemente se originan dentro de los programas son responsabilidad del Mac OS, y nadie sería capaz de decir que el Mac OS es tan fiable como el Linux. Pero también es verdad que Linux, ante todo, es un sistema operativo para servidores, mientras que con el Mac OS trabajan principalmente usuarios individuales, cuyas acciones son bastante más impredecibles para un programador.

Finalmente, Eric y sus ideas sobre el código abierto se toparon con la mayor resistencia cuando empezó a criticar el modelo de la programación comercial. Desde su punto de vista, pese a que la creación de programas comerciales es la mayor aspiración de un programador, la mayor parte ellos se dedican al mantenimiento de los sistemas informáticos de las empresas. Aunque ahí la mayoría estuvo de acuerdo, tambien es cierto que no es frecuente desarrollar con Macs los sistemas de las empresas, y gran parte de la audiencia se ganaba la vida vendiendo programas informáticos. Durante un momento las pasiones afloraron, ya que la audiencia interpretó las críticas de Eric al modelo de programacion comercial como un ataque a su forma de vida. Afortunadamente prevalecieron aquellos con la mente más fría: todos se relajaron y se dieron cuenta de que, efectivamente, la industria del Macintosh ya se está alejando del modelo de la programación comercial. Los productos secundarios (como los módulos de Photoshop), el material de aprendizaje, la documentación, los programas a medida, el soporte técnico basado en suscripciones, e incluso la publicidad. Todo esto sustituye o se añade al precio de venta. Y en cualquier caso, debido a que los programas para Macintosh siempre han tenido dificultad para encontrar espacio en las tiendas de informática, todos nos hemos acostumbrado ya tanto a comprar como a distribuir programas por métodos "no estándar". Esto sólo debería favorecer la tendencia a alejarnos aún más del modelo de la programación comercial.

El Entendimiento -- Eric Raymond merece toda nuestra admiración por aguantar en la tarima, desde la medianoche hasta las seis de la mañana, discutiendo con toda una sala llena de desarrolladores para Mac. La tozudez era respondida con más tozudez; la firme creencia de llevar la razón es un rasgo típico de los programadores. Eric también merece nuestra admiración por afirmar claramente que la comunidad del código abierto necesita aprender del mundo del Macintosh, tanto en la forma de crear buenas interfaces de usuario como en la de hacer negocio con un mercado de consumo. Por su parte, los desarrolladores de MacHack admitieron, algunos de corazón y otros a regañadientes, que el modelo de código abierto también podría resultar de extrema utilidad para el mundo del Mac.

La situación fue incluso a más según avanzaba la conferencia, puesto que Eric no se limitó a hablar y largarse - se quedó por allí durante toda la conferencia y se vio atrapado por el ambiente. Leonard Rosenthol, veterano de las quince conferencias de MacHack y gran defensor del modelo de código abierto para los programas de Macintosh, sugirió que entre todos soltáramos algún dinero para comprarle a Eric un iBook en el CompUSA de al lado. Un día más tarde, la caja de "Compremos un iBook para Eric Raymond" había acumulado tantos billetes que se le obsequió con un iBook color arándano, con RAM de más y una selección de programas de las compañías representadas en MacHack. En el momento de la entrega, se quedó helado, e incluso participó, junto con Maurita Plouff, en el Concurso de Hacks - rutinas ingeniosas o trucos de programación [Lluc] - con una rutina escrita con el lenguaje de guiones Python.

Al final, Eric prometió su vuelta a MacHack y propuso una conferencia de OpenHack tomando como modelo el enfoque y la cultura de MacHack. Ambos ayudarían a unir los lazos entre los partidarios del código abierto y la comunidad Macintosh, en beneficio de todos nosotros.


Servicios Internet desde un PowerBook 5300

por Ron Risley <ron@risley.net>

Hace ya un año que fui seducido.

Yo fuí uno de los primeros en adoptar la RDSI, pero años más tarde me dió la sensación de que nunca llegaría a cumplir lo que me prometieron. Ahora que el ADSL está disponible en mi área, y puesto que tengo la centralita a un tiro de piedra de mi casa, deduje que obtendría excelentes resultados, ya que el ancho de banda disponible por ADSL depende, en parte, de la longitud y estado de los cables entre la centralita y tu instalación.

La instalación de mi linea ADSL fue rápida y sin problemas, a pesar de las complicaciones a causa de la conversión desde la RDSI. Para mantener la línea ADSL aislada del resto de mi red, Pacific Bell me suministró una tarjeta Ethernet PCI para mi Mac. Mi velocidad de descarga alcanzaba los 1,5 megabits por segundo (Mbps), aunque PacBell recortó mi ancho de banda de carga hasta los 128 Kbps.

<http://www.pacbell.com/>

Repartiendo la alegría -- No podía estar más contento, aunque esta nueva conexión super-rápida y de activación inmediata sólo funcionaba en mi ordenador principal. El iMac de Kim, mi mujer, apenas a 2 metros de distancia, seguía atado a un módem analógico de 56 Kbps (y puesto que nuestra línea de voz usa el mismo par de cables que la conexión ADSL, ella ya no podía navegar y hablar a la vez). Otras máquinas abandonadas, esparcidas por toda la casa, no tenían ningún tipo de acceso a Internet. Necesitábamos compartir de algún modo esta nueva fuente prodigiosa de ancho de banda.

Con una búsqueda rápida por la Web descubrí unos cuantos routers ADSL. Estos dispositivos se conectan a una línea ADSL y una red Ethernet al mismo tiempo y pueden compartir una única dirección IP entre varias máquinas usando la Traducción de Direcciones de Red (NAT). Justo lo que necesitaba, con la salvedad de que tanto Kim como yo somos médicos residentes, lo que significa que apenas si superamos el salario mínimo. Los 200 US$ de la instalación de la línea ADSL habían ya diezmado mi presupuesto para informática de varios meses, y los routers ADSL de compañías como Netopia no bajan de los 500 US$.

<http://www.faqs.org/rfcs/rfc1631.html>
<http://www.netopia.com/>

Se me ocurrió que debería haber alguna solución basada en programas informáticos. Otra búsqueda descubrió SurfDoubler de Vicomsoft e IPNetRouter de Sustainable Softworks.

<http://www.vicomsoft.com/>
<http://www.sustworks.com/>

El producto de Vicomsoft tenía una interfaz amigable y elegante, pero limitaba el número de usuarios simultáneos a dos o tres. Me gustó el enfoque de IPNetRouter de aumentar el considerable poder ya presente en Open Transport. La interfaz parecía mas flexible y mucho mas orientada a la gente con conocimientos informáticos, y como yo soy uno de esos, me bajé la demo gratuita.

IPNetRouter hacía todo lo que su autor, Perter Sichel, prometía. Me pasé bastante del presupuesto al registrar el programa de 89 dólares (las versiones para el mercado educativo y las actualizaciones desde productos de la competencia tienen buenos descuentos), y en unos minutos el iMac de mi mujer estaba disfrutando del mismo acceso a Internet sin cadenas que yo tenía. Sin cadenas, claro, mientras mi ordenador estaba en funcionamiento. Lo que presentaba un problema: a mí me gusta programar a bajo nivel, lo que significa que mientras hago pruebas mi ordenador se cuelga a menudo y tengo que reiniciarlo. También odio el ruido del ventilador y derrochar electricidad. Mantener en continuo funcionamiento mi SuperMac S-900 con dos ventiladores y dos monitores cuando no lo estaba usando era bastante molesto.

Servicio a tiempo completo -- Me habian dicho que IPNetRouter no utilizaba demasiados recursos del procesador. Tenía un viejo PowerBook 5300cs abandonado con la pantalla y el trackpad averiados. La molestia y el dinero necesario hacían que no mereciera la pena arreglarlo, pero el procesador todavía funcionaba bien. No tenía ventilador, usaba poca energía, e incluso tenía una reserva de energía con su batería. ¿Podría funcionar como un router?

Pues claro que podía. Le conecté un monitor externo y un ratón el tiempo suficiente para instalarle el programa Virtual Network Computing (VNC) de AT&T, que permite a un ordenador remoto reflejar la pantalla y enviar órdenes de ratón y teclado a través de Internet. (Ver el reportaje de Kevin Savetz sobre las versiones más recientes de VNC en TidBITS-441). No era tan estable ni con tantas posibilidades como Timbuktu de Netopia, pero haría el trabajo y, al salirme gratis, se ajustaba a mi presupuesto. Compré una tarjeta Ethernet tipo PC Card a Small Dog Electronics, uno de los patrocinadores de TidBITS, por 19 dólares, instalé IPNetRouter en el PowerBook, y lo conecté a mi concentrador (hub) Ethernet .

<http://db.tidbits.com/getbits.acgi?tbart=05021>
<http://www.uk.research.att.com/vnc/>
<http://www.netopia.com/software/>
<http://www.smalldog.com/>

Lo que había comenzado como un simple cambio desde RDSI a ADSL se había convertido en un pequeño pero importante proyecto para construir una LAN ( Local Area Network, "Red de Area Local"). Ahora tenía una conexión a Internet estable, rápida, 24 horas al día y 7 días a la semana, que podía ser compartida por todos los ordenadores de mi casa. Podrías pensar que estaba satisfecho.

Pero enseguida se presentó otro problema.

Una Web de mi propiedad -- He tenido un sitio en la Web desde hace mucho tiempo, pero siempre me había conformado con ponerlo en el servidor de mi Proveedor de Servicios Internet (PSI). ¿Por qué debería haberme tomado la molestia de mantener un servidor constantemente, cuando se incluye un espacio para sitios web como parte del contrato con la mayoría de los proveedores? El PSI que usaba para mi conexión RDSI anterior, sin embargo, no daba soporte ADSL. Eso significaba que tendría que trasladar mi sitio, lo que implicaba reescribir la mayor parte de las páginas que usaran recursos específicos del servidor (mayormente los CGIs - Common Gateway Interface o Interfaz de Acceso Común - que gestionaban los formularios y mandaban los datos por correo electrónico) para que fueran compatibles con los servidores de PacBell. PacBell también limita las cuentas de ADSL a 3 megabytes de espacio en servidor, lo cual iba a dejar un poco apretado el espacio para mi sitio. Los servidores gratuitos existen, pero generalmente a condición de que pongas anuncios, y siempre me he enorgullecido de que mi sitio web estuviera libre de publicidad. Podría contratar más espacio de servidor de PacBell u otros, pero estaba otra vez el maldito problema de extralimitarse en el presupuesto.

Clavé la mirada maliciosamente en el 5300cs bajo mi escritorio. Siempre encendido. Siempre conectado. Con una IP estática. Cientos de megas gratis de espacio libre. ¡Oye, si era el perfecto candidato a servidor!

Como nunca había tenido necesidad de un servidor Web, tampoco había prestado atención a qué programas había por ahí. Sabía algo acerca de WebSTAR de StarNine, pero este programa se me salía completamente de presupuesto. Mi breve búsqueda de un servidor de bajo coste fue recompensada cuando recordé que el Compartir Web Personal de Apple se incluye en el Mac OS desde la versión 8.0 y que funciona bajo Mac OS 7.6 [Otra opción es NetPresenz, la venerable utilidad shareware que ofrece servidores de Web, FTP e incluso Gopher, pero su precio de 75 US$ es superior al gratuito del Compartir Web. Ron finalmente cambió a NetPresenz, pero tiempo después de la historia que cuenta este artículo sobre su odisea a la búsqueda de un servidor. -Geoff]

<http://www.starnine.com/>
<http://asu.info.apple.com/swupdates.nsf/artnum/n10773>
<http://www.stairways.com/netpresenz/>

Activé el panel de control Compartir Web, copié los ficheros de mi web en el 5300cs y ya estaba alojando mi propio sitio web! Me sorprendió ver que el Compartir Web incluso utiliza el panel de control Ficheros Compartidos para dar funciones de autenticación básicas (páginas con acceso por contraseña), y scripts CGI. Pronto descubrí que hay un caudal de CGIs programados en Applescript en la Web, e instalé el venerable Email CGI para hacer funcionar mis formularios.

<http://cgi-resources.com/Programs_and_Scripts/AppleScript/>
<http://www.lib.ncsu.edu/staff/morgan/email-cgi.html>

¿Correo electrónico? Sí, ¿por qué no? -- Acceso de alta velocidad para todas mis máquinas, un servidor Web local con centenares de megas para con los que entretenerse, libertad para escribir mis propios programas CGI... con eso ya sería bastante, pero me había picando la curiosidad sobre los servidores. Siempre quise alojar algunas listas de correo para ayudar a mis colegas a comunicarse mejor, pero nunca tuve acceso a un servidor de listas. Me acordé de Macjordomo, un servidor de listas de correo que hay desde hace bastante, y me sorprendió encontrarme con que todavía era gratuito.

<http://leuca.med.cornell.edu/Macjordomo/>

Macjordomo no exige que pongas un servidor de correo propio, pero mientras lo configuraba me di cuenta de que necesitaría varias direcciones para cada lista, pensando en las recomendaciones que se publicaron en TidBits para la gestión de listas de correo (aunque aún no he establecido todas las cabeceras).

<http://db.tidbits.com/getbits.acgi?tbart=05321>

Seguro que podría conseguir buzones extra de PacBell, pero entonces la fea cabeza de esa cosa llamada presupuesto asomaría de nuevo. No obstante, la documentación del Macjordomo mostró un par de servidores de correo POP y SMTP gratuitos. Esos podrían proporcionarme todos los buzones que necesitaba. Primero, valoré el Eudora Internet Mail Server (EIMS) - Servidor de Correo Internet de Eudora -, ya que soy un gran fan de este programa. La versión comercial está bien, pero está fuera de mi capacidad presupuestaria. La versión gratuita también parece funcionar, y tiene sus adeptos, pero no conseguí que sus capacidades de anti-retransmisión (anti-relay) funcionaran como yo deseo. Viviría sin vivir en mí si cualquiera pudiera utilizar mi sitio para retransmitir correo basura. Así que, en su lugar, utilicé el Stalker Internet Mail Server (SIMS) - Servidor de Correo Electrónico de Stalker - un servidor flexible con unas magníficas capacidades anti correo basura.

<http://www.eudora.com/freeware/servers.html>
<http://www.stalker.com/SIMS/>

Ahora podría crear cuantos buzones de correo electrónico quisiera, y durante el proceso había resuelto otro problema: muchos de mis pacientes prefieren comunicarse conmigo por correo electrónico. Algunos protegen su correo usando PGP, pero para otros es demasiado complicado. Me preocupaban sus mensajes residiendo, sin protección alguna, en un servidor POP cualquiera. Aunque los mensajes pueden ser interceptados mientras se transmiten, por lo menos ahora iban directamente a un ordenador que yo controlo.

¿Qué esconde un nombre? -- Seguro que eso sería la guinda del pastel. Ya tenía un servidor para el correo electrónico y la Web, un gestor de listas de correo y un router equipado con NAT. Lo había conseguido todo por unos 200 dólares. El único problema era que la "amigable" DNS que PacBell había adjudicado a mi PowerBook 5300 era asquerosa -más de 40 caracteres, una ensalada de letras, números y espacios. ¿Cómo podría un ser humano recordar una dirección de correo electrónico en un sitio que tiene un nombre que parece escrito a base de dar puñetazos al teclado?

Lo admito: siempre he suspirado por una dirección personal en Internet. Ahora tenía la excusa, y con la apertura del proceso de registro de nombres de dominios, los precios estaban cayendo. Significaría gastar un poco más de dinero, pero a esas alturas ya había ahorrado un poco a base de saltarme comidas intentando hacer funcionar el programa del servidor. Hice el registro por dos años con Network Solutions, al precio de 70 dólares.

<http://www.networksolutions.com/>

y ahora, otra pega: para registrar un dominio tienes que tener dos servidores de nombres de dominio (DNS) distintos - idealmente, en partes de Internet geográficamente alejadas. De nuevo, estos servicios se pueden adquirir a un amplio espectro de vendedores, pero necesitaba una solución más compatible con mi bolsillo.

Afortunadamente, hay dos servidores de nombres gratuitos disponibles para Mac OS. Pero primero una advertencia. Con algo de perseverancia y paciencia, casi todo el mundo puede llegar hasta aquí con éxito. La Web, el correo electrónico, el programa servidor de listas de correo, todo gratuito, son generalmente de gran calidad, bien documentados y más o menos fáciles de usar. El sistema DNS, sin embargo, no se distingue precisamente por ser asequible a todos los usuarios. Comprender los arcanos asociados a los servidores de DNS y sus archivos de zona, puede ser un reto abrumador. Si te vas a amilanar y vas a pagar a alguien para que te administre parte de tu sitio, o soltar un buen montón de billetes por un producto comercial, amigable y con servicio técnico (como el QuickDNS de Men&Mice, por 290 US$), desde luego yo empezaría por las DNS.

<http://www.menandmice.com/>

Hay que reconocer que Apple ya intentó allá por 1995 ponerle una cara amable a la gestión de los DNS, cuando comenzaron a coquetear con la idea de soportar servidores de Internet sobre Mac. Con MacDNS se puede conseguir un servidor de nombres de dominio en minutos, aunque sus capacidades son limitadas, su rendimientobajo y su estabilidad, altamente cuestionable (aunque algunos dicen usarlo sin problemas). Está disponible como descarga gratuita desde la web de Apple, pero no ha sido actualizado desde 1996.

<http://db.tidbits.com/getbits.acgi?tbart=01532>
<http://asu.info.apple.com/swupdates.nsf/artnum/n11264>

NonSequitur es una alternativa para expertos en Unix y otros usuarios que gustan de desentrañar los misterios de los ficheros de zona con formato BIND (BIND-format). Este programa es un pequeño y rápido servidor de nombres de dominio que resulta ser, además, sumamente estable. Es también gratuito, y es el servidor de nombres que he escogido. Tanto MacDNS como NonSequitur utilizan el formato BIND, por lo que es posible utilizar MacDNS para crear los ficheros de zona y posteriormente usarlos con NonSequitur, aunque aún no lo he probado.

<http://www.gross.net/sw/nonsequitur/>

Proporcionar un DNS secundario resultó más problemático. Yo solamente tenía una dirección IP, por tanto, mi servicio secundario tendría que estar alojado en otra parte. Como solución temporal, utilicé un ordenador de mi trabajo que estaba en desuso temporalmente. Por lo general, un DNS ocupa un bajo nivel de ancho de banda, y puede permanecer en segundo plano y pasar casi inadvertido en los sitios con poco volumen de trabajo, pero esta solución no resultó ser satisfactoria - pues ni siquiera los escasos ciclos que parecía estar utilizando eran realmente míos.

Hay una solucion ideal: como el acceso de alta velocidad es cada vez más frecuente, se podrían crear sencillos acuerdos de hospedaje de DNS : usted me proporciona un DNS secundario y yo otro a usted. Desgraciadamente, ningún programa para DNS gratuito del Mac OS soporta este concepto. La mayoría de estas aplicaciones pueden actuar como servidores secundarios, previo requerimiento del servidor primario, así los archivos de zona no tienen que ser sincronizados a mano entre los dos servidores. MacDNS y NonSequitur actuarán como servidores primarios, pero no soportarán un DNS secundario. Un buen AppleScript probablemente podría salvar esta limitación, pero ese proyecto esta actualmente languideciendo en mi montón de buenas intenciones. El programa comercial QuickDNS Pro, ofrece servicios secundarios, pero cuando mi presupesto se recuperó un poco, terminé comprando un servicio de DNS secundario. Varios proveedores ofrecen DNS secundarios por un dólar o dos al mes.

<http://www.backupdns.com/>
<http://www.nols.com/dnservice.html>
<http://www.secondary.net/>

Comparte equitativamente -- Todo lo anterior ya debería ser suficiente, pero todavía quedaba una pieza que quería poner en su lugar. Yo estaba trabajando en otro proyecto que requería algún hospedaje de servicios de Internet. Ahora que tenía todas las piezas en su lugar, ¿Cuán difícil iba a serme añadir otro dominio a mi servidor?

Pronto me sentí descorazonado. Con el fin de administrar bien el escaso número de direcciones IP, existen estándares bien establecidos para compartir una única dirección IP entre varios sitios Web - lo que se llama hospedaje virtual. Sin embargo, las implementaciones del hospedaje virtual para el Mac OS parecen limitarse a los módulos de WebStar. Estuve rumiando la idea durante unos días antes de que se me ocurriera que un guión CGI podría resolver el asunto. Cuando me puse a escribir el guión descubrí que era asombrosamente sencillo. En su forma más simple, se puede lograr el hospedaje múltiple en un servidor Web con sólo tres líneas de AppleScript. Incluso después de añadir algunas líneas de código para refinarlo y detectar errores, el guión no llega a ocupar una pantalla y permite acoger un número ilimitado de sitios Web desde una única dirección IP.

Amos del universo virtual -- Todos conocemos el aforismo de A.J. Liebling "La libertad de prensa solo está garantizada para aquellos que poseen un periódico". Lo que me gustaría destacar es la impresionante forma en que Internet ha reducido el coste de poseer un periódico. La mayor pieza del puzle, con diferencia, fue conseguir el tiempo de acceso ilimitado a Internet, pero el resto del trabajo de crearse un sitio en Internet listo para funcionar requirió poco dinero, un ordenador mediano y bastante tiempo libre.

Cuando en el pasado había considerado la posibilidad de poner en marcha mi propio servidor, siempre pensé que lo instalaría sobre Linux. Mirando ahora hacia atrás, me alegro de haberme decidido por el Mac OS, aunque no fué algo premeditado. Me convenció como no lo hubiera hecho ninguna otra cosa de cuán viable es el Macintosh como plataforma para Internet.

Se puede encontrar más información acerca de la instalación de servicios para Internet en el libro "Providing Internet Services via the Mac OS", de Carl Steadman y Jason Snell que se puede obtener en Internet. Aunque el libro se publicó a mediados de 1996 y en algunas cosas se ha quedado bastante atrasado, en su momento era muy completo y en lo fundamental sigue siendo tan válido como siempre.

<http://www.pism.com/>

[Ron Risley pudo haber sido un empresario de Internet, pero en lugar de eso dejó el ejercicio de la consultoría en comunicaciones en 1986 para continuar una nueva carrera como psiquiatra y médico de familia.]

<http://www.risley.net/>


Las publicaciones no comerciales y sin ánimo de lucro tienen permiso para reproducir los artículos, siempre y cuando se de completa noticia del autor y la publicación originales. Para la reproducción en otro tipo de publicaciones, sírvanse en contactar con nosotros previamente. No se garantiza la exactitud del contenido de los artículos. Avertencia al lector!. Los nombres de cada publicación, producto o compañía pueden ser marcas registradas de sus respectivas compañías. TidBITS ISSN 1090-7017.

Número Anterior | Buscar en TidBITS | TidBITS Home Page | TidBITS-es | Siguiente número