*nix pro

La certificación RHCE (Red Hat Certified Engineer) es considerada una de las más prestigiosas dentro del mundo de Linux. ¿El motivo? Además del respaldo de Red Hat, es sabido (y si no lo sabéis, os pongo al día en un momento) que el examen difiere de la mayoría de las certificaciones en un punto fundamental: es un examen práctico (de 3,5 horas, hay que advertir). Esto garantiza que los que consiguen superarlo tienen los conocimientos prácticos necesarios para el ejercicio de la Administración de Sistemas con Red Hat Enterprise Linux.

Llevo con Linux desde 1993 y administrando sistemas Linux a diario con distribuciones de Red Hat o sus derivados (Fedora, CentOS) desde 1996. Ya iba siendo hora de ponerme a prueba, además del día a día, así que decidí pasar la prueba del RHCE. Como en *nix pro somos grandes en méritos pero pequeños en recursos, decidí ir directamente al examen (RH302), saltándome el curso (RH300). Dado que según un examinador oficial (RHCX), el RHCE lo suele aprobar a la primera el 40% de la gente que asiste al curso y el 10% de los que no lo hacen, la decisión parecía arriesgada. Pero era un riesgo calculado, así que seguí adelante con el plan.

Lo primero que debería hacer un candidato al RHCE es pasar la prueba de evaluación. Esta prueba es gratuita (requiere registro en Red Hat, también gratuito) y le permite a uno saber su nivel básico. Consta de tres partes, que valoran los conocimientos que se adquirirían en los cursos RH033, RH133 y RH253 (estos dos últimos se comprimen en la mitad de tiempo en el RH300). Si no sois capaces de superar estas pruebas con una puntuación mínima, dejadlo. No lo intentéis. En su lugar, pegáos a los libros, haced los cursos, o ambas cosas. Los conocimientos que se miden son fundamentales para seguir adelante, así que es mejor no perder el tiempo y asegurarse cierto nivel.

Lo siguiente sería un repaso a las cuestiones que formarán parte del examen. Dado que el único misterio con respecto al examen son las preguntas concretas, y no los temas, podemos fácilmente encontrar en Red Hat la guía de preparación. En ella está condensada la planificación a seguir, incluyendo los prerequisitos sin los cuales, es necesario insistir, mejor ni intentarlo. Además, también vemos la lista de habilidades que se van a poner a prueba, tanto en el RHCT como en el RHCE. Si no se supera todo el examen, bien se puede obtener el RHCT (Technician en lugar de Engineer), o bien plantearse desde un comienzo ir a por esta otra certificación.

A continuación, hay que seleccionar el material de estudio. Ya que se trata de un examen práctico, es necesario (¿hay que decirlo?) practicar. Lo voy a repetir por si no ha quedado claro: lo único que cuenta en este examen es resolver correctamente los problemas que se plantean, así que un problema a medio resolver cuenta como no resuelto.

El material de estudio puede venir de muy diversas fuentes, pero la primera que habría que considerar es, precisamente, Red Hat. Muy recomendable la lectura de los documentos Deployment Guide e Installation Guide. Además de practicar (y practicar, no lo olvidemos), puede ser más que recomendable adquirir algún libro, digamos, más (allá va otra vez la palabra) práctico. Hay muchos de ellos orientados a aprobar el examen, de los que habría que seleccionar alguno que tenga (lo habéis adivinado) problemas prácticos que resolver.

Con respecto a esto de practicar (os habéis adelantado esta vez), es recomendable tener un ordenador aparte (o más, para probar los servicios de red) sobre el que hacer las instalaciones, configuraciones y demás operaciones. También puede ser una o más máquinas virtuales, que fue mi opción. En cualquier caso, hay que tener en cuenta que tanto unos como otras pueden quedar bastante maltrechos como resultado de las prácticas, en especial las de resolución de problemas de arranque y de servicios mal configurados. Para esto último, ayuda tener un compañero que nos pueda “sabotear” la instalación (y al cual devolverle el “favor” si es que también se presenta al examen). Yo no tuve esta ayuda, pero me hubiera venido bien.

Una vez superado todo esto, podemos ir a la página de Red Hat y ver cuándo es el próximo examen en nuestro rincón del mundo. También podemos hacerlo al revés, y primero seleccionar la fecha para después hacer el plan de estudio. Este último método, aunque es algo menos seguro, tiene la ventaja de que sube el nivel de adrenalina, especialmente si tenéis que trabajar, tenéis SO (agradezco enormemente su enorme paciencia) o ambas cosas. He de decir que, aunque seguí mis propias recomendaciones de estudio, el grueso del mismo y todas las prácticas tuvieron lugar en las dos semanas previas al examen, incluyendo un catarro que amenazó con frustrar por completo el plan :/

Llegó la hora de la verdad. Éramos diez candidatos en un aula bien dispuesta. Nuestro examinador se preocupó de que estuviéramos cómodos y de que las instrucciones fuesen claras. Incluso explicó la mecánica del examen en inglés para los candidatos que no hablaban español. Nos informó también de que los resultados se nos enviarían por correo electrónico en tres días laborables (de EE. UU.).

Lo primero que hicimos fue rellenar nuestros datos y firmar un acuerdo de confidencialidad (NDA, para el que no sepa español), por lo que lo que os puedo contar del examen es muy limitado. Mucho.

• dura 3,5 horas
• es totalmente práctico (por si no lo había dicho antes)
• hay que llevar DNI o documento identificativo similar
• no se puede usar móvil, PDA, ordenador portátil, apuntes, libros, etc
• se puede escribir en una hoja de papel (suministrada por ellos), que luego recogen
• más vale que hayáis dormido bien y seguido un plan de estudios efectivo
• lo primero, las preguntas que mejor sepáis para conseguir el mínimo de 70 puntos en cada parte
• hay que saberse mover por el sistema, especialmente con la documentación
• no hay conexión a internet
• no hay tiempo que perder
• hay que probar los cambios que se hagan

Las tareas están a la altura de lo que se pide en la guía de preparación, pero una lectura de un libro práctico es más que recomendable. Recomiendo vivamente confeccionar una guía personal de consulta con los puntos que uno tenga menos frescos para su estudio posterior. A mí me resultó sumamente práctico, pues a la hora de repasar, uno puede estar tentado por mirarlo todo y puede no haber tiempo.

¿Que cómo me fue? Teniendo en cuenta la complejidad del examen, el tiempo que le dediqué a la parte práctica y que la noche anterior dormí poco (aún me ponen nervioso los exámenes, ¿podéis creerlo?), el resultado (que recibí esa misma tarde) fue más que satisfactorio: superé los 90 puntos. Hasta te envían un documento PDF para que puedas imprimir tu propio título y colgarlo de la pared, qué majos :)

Estos días se han dado dos noticias de gran importancia en el mundo *nix: la sentencia final del caso SCO vs Novell (que casi llegó a ser “SCO vs *”) y el cambio de licencia de Solaris por parte de Oracle.

Sobre lo primero, el Salt Lake Tribune ha publicado un artículo en el que se deja claro que el jurado ha puesto el punto y final a seis años de litigio, reconociendo que Novell posee los derechos del *nix original, y no SCO (que, recordemos, proviene de una división de Novell llamada Caldera y posteriormente renombrada como “SCO Group”; no debe confundirse con lo que en su momento fue The Santa Cruz Operacion y que posteriormente se renombró a Tarantella). Supongo que esto no será el fin, puesto que el derecho al pataleo y las amenazas vacías son prerrogativa de cualquier empresa o particular, pero a partir de ahora quedará claro que de esto es de lo que estamos hablando, y no de derechos de autor. Una de cal para el mundo *nix. Si es que la cal era buena para algo, que me dicen que sí.

La arena sale en esta ocasión de Oracle. En efecto, nada mejor para una máquina (sea real o virtual) que tener todos sus engranajes en perfecto estado de mantenimiento, engrasándolos cuando es necesario. Y nada peor que introducir arena en tales engranajes. O, como en este caso, cambiar la licencia de uso de Solaris. Oracle, en su intento de sacar hasta el último kopek de sus adquisiciones, ha convertido (afortunadamente, sin efecto retroactivo) a Solaris en un sistema que requiere licencia para uso más allás de los 90 días de prueba que ahora se conceden. Antes, la licencia de uso era a perpetuidad, al margen de que necesite una suscripción para las actualizaciones (esto no ha cambiado).

¿Puede OpenSolaris salvar al mundo libre de esta situación, conservando lo mejor de Solaris? Tal vez… siempre que Oracle no decida que su personal dejará de mantener el código y que al mismo tiempo la comunidad de OpenSolaris esté lo bastante ducha para hacerlo en cualquier caso. El tiempo lo dirá.

No “cómo escribir un libro”. En este artículo quiero hablar muy someramente del proceso de creación de un libro con herramientas libres que están disponibles en sistemas *nix populares. Nuestro objetivo es alcanzar un resultado profesional con el mínimo esfuerzo necesario, obteniendo un fichero PDF que pueda enviarse a imprenta (algunas admiten otros formatos, pero este será el que nos dé menos sorpresas al final). Esto es válido tanto para la tripa (el interior del libro) como para la cubierta (el exterior). No hablaré de la sobrecubierta, pero se aplicarían los mismos principios que para la cubierta. Comenzamos.

Lo primero, es la elección del sistema para escribir el libro. Sobre esto hay dos grandes escuelas: la de los procesadores de textos y la de los editores separados del sistema de formato. Si eres nuevo en esto, o vienes de usar un procesador de textos, mi recomendación es el uso del formato OpenDocument. Algunos productos libres que lo editan son OpenOffice.org (tal vez el más recomendable), KWord (de la suite KOffice) y Abiword. Con ellos te sentirás como en casa. OpenOffice.org puede exportar directamente a PDF; los otros no lo sé, pero siempre se puede instalar la impresora virtual CupsPDF y generarlo tranquilamente.

Si, por el contrario, estás acostumbrado a usar $EDITOR (sin olvidar que hay un mundo más allá de Emacs y vi), y tu formación es tećnica, es probable que prefieras un sistema de formato aparte. Por experiencia, recomiendo vivamente LaTeX, aunque también existen alternativas como Lua, DocBook y hacerlo directamente en HTML (esta opción sólo la he empleado para documentos cortos). Me gustaría señalar que los formatos de la familia de  ROFF se han usado profusamente en otros tiempos para estos menesteres. Mi experiencia personal con LaTeX ha sido tan satisfactoria que, a pesar de un corto romance con OpenOffice.org, regresé alegremente y no me he arrepentido. Por lo menos puedo decir que he probado ambos mundos.

Es MUY IMPORTANTE que, sea cual sea el método empleado, nos aseguremos de  que el PDF generado contiene todas las fuentes tipográficas que vayamos a usar. Para verificarlo, basta con ver las propiedades del documento final (con evince, Adobe Reader o cualquier lector de PDF decente).

Una vez elegida nuestra herramienta, será necesario familiarizarnos con ella. Para conseguirlo, nada mejor que acceder a una buena documentación. Hay buenos manuales, dentro y fuera de internet, por lo que en cuanto notemos que nuestros conocimientos flaquean, no debemos dudar en consultarlos. En este aspecto, los procesadores de textos son probablemente más fáciles de usar para el usuario ocasional.

Sea cual sea la herramienta elegida, recomiendo vivamente el uso de plantillas. El objetivo final es producir un PDF con un formato determinado, para lo cual debemos auxiliarnos de una documentación adecuada. Si lo tuyo es aprender cómo se hacen las cosas profesionalmente en cuanto al formato del libro, de la página y del texto, lo mejor será consultar con alguna obra especializada sobre composición tipográfica. Si, por el contrario, no tienes esa necesidad o estás pensando en contratar los servicios de una imprenta (ya sea “bajo demanda” o “tradicional”), es bastante probable que te puedan orientar con algún manual al efecto. En cualquier caso, una rápida consulta con quien tenga que poner sobre el papel tus palabras te dará la respuesta de cómo distribuir las páginas y qué medida del papel usar. Como dije antes, el uso de plantillas te van a permitir cambiar fácilmente la distribución del material sobre la página en toda la obra, así como las tipografías a usar, sin tener que ir cambiándolo fichero por fichero. Cuando tienes más de 50 capítulos, esto puede marcar la diferencia. Con LaTeX, este problema viene resuelto de serie, pero con OpenOffice.org puede y debe hacerse. Basta con elegir estilos lógicos (y no físicos) para los encabezamientos y el cuerpo, para que con un simple cambio todos muten simultáneamente. Insisto, el uso de plantillas nos puede ahorrar un trabajo inmenso, hasta el punto de que algunas imprentas las facilitan.

Una vez terminada la obra (¡qué fácil es decirlo!), ya tendremos la tripa preparada. Llega el momento de preparar la cubierta. De nuevo, la imprenta nos dirá el tamaño del fichero (en cm o en puntos o en la medida con la que trabajen ellos) que le tenemos que facilitar. Hay que tener en cuenta la parte que ellos cortarán, así como el lomo. De ahí que sea necesario saber exactamente el número de páginas de la tripa para determinar las dimensiones exactas. Puede que nos pidan una imagen a una determinada resolución.

Supongamos que dicha imagen es en formato JPEG a 300 puntos por pulgada. Lo primero que tenemos que tener en cuenta es que la imagen debe ir en la máxima calidad posible, lo que en el caso de JPEG significa que hay que generarla sin usar compresión, es decir, calidad 100%. La compresión del formato JPEG es con pérdidas, a diferencia de, por ejemplo,  la del formato PNG. Para ello, podemos usar muchos programas, cuya elección dependerá de cómo tengamos pensado crear la cubierta. La cubierta anterior debe contener el nombre de la obra y el del autor o autores (información que repetiremos en el lomo), siendo típico incluir alguna imagen que represente el contenido o que inspire al lector ganas de leer la obra. La cubierta posterior suele contener un “gancho” (si es ficción) o un resumen (si es ensayo o libro técnico), así como una breve biografía del autor, además del ISBN (si lo tenemos) y su código de barras asociado. El nombre de la editorial y la colección también estarán aquí, además de en el lomo.

Queda claro que la cubierta posterior puede tener menos necesidades gráficas que la anterior, por lo que aquella podría componerse directamente con el mismo sistema que la obra; mientras que la anterior puede requerir cierta edición gráfica. En este último caso, dependiendo de si nuestra imagen es vectorial o no, podemos tratarla con inkscape o con GIMP, respectivamente. En mi caso, para una obra de reciente creación, generé tanto la cubierta anterior como la posterior con LaTeX, y después las ensamblé con inkscape, añadiendo en este último paso la información del lomo.

Para el código de barras del ISBN podemos emplear el paquete pst-barcode de LaTeX y generarlo directamente en el documento. Si no es nuestro caso, podemos buscar e instalar alguno de los generadores de códigos de barras libres que hay, o bien visitar una de las páginas de internet que existen a tal efecto.

Una vez enviadas la tripa y la cubierta, será preceptivo verificar el resultado para cerciorarnos de que todo está en orden. Lo que hagamos después, dependerá de que nuestra intención sea publicar, vender, repartir, o engordar nuestro ego. Una nota final: si nuestro objetivo es distribuir la obra en formato electrónico, no estará de más considerar la conversión a otro formato más idóneo para tal fin; o bien, crear una versión PDF adaptada a los lectores de libros, con márgenes, tipografías y tamaños de letras adecuados. El papel y la pantalla son medios distintos que tienen diferentes necesidades.

No hace mucho he leído un par de discusiones sobre los formatos de audio digital y la “indistinguibilidad” del MP3 (MPEG-1, nivel 3, recordémoslo) y la fuente original. Evidentemente, o bien los voluntarios no han escuchado más que MP3 a lo largo de su existencia, o los equipos de sonido que usaron para las pruebas (auriculares incluidos) no eran de buena calidad.

Sí es cierto que para niveles suficientes de calidad de los componentes y dependiendo del grado de compresión deseado y del entorno en que se escucha la música, se puede lograr un compromiso más que aceptable usando un formato de compresión con pérdidas. Por motivos técnicos e ideológicos, mi formato favorito es el Vorbis (más conocido como “OGG” por el nombre del contenedor Ogg que lo suele incorporar): su calidad suele superar a la del MP3 de velocidad equivalente, además de ser un formato libre de patentes. La duda puede venir cuando necesitamos cierta, digamos, interoperatividad.

En ese caso, mi consejo es claro: capturar el audio en formato FLAC, conservando sin pérdidas el sonido original y (esta, además del ahorro en espacio, es la diferencia más interesante con respecto al formato WAV) permitiendo almacenar las etiquetas de la música como comentarios Vorbis: autor, álbum, fecha, etc. Como suele decirse, hoy en día el espacio en disco (especialmente el externo) es barato.

Posteriormente, dependiendo de nuestras necesidades, podemos generar a partir del fichero FLAC otro OGG, MP3 u otros formatos. En el primer caso, la conversión de etiquetas es directa y el propio programa oggenc se encarga de ello. Para el formato MP3, necesitaremos alguna ayuda extra (flac2mp3 me viene a la cabeza). En mi caso, dado que tanto en el ordenador como en mi DAP tengo la posibilidad de escuchar Vorbis (tanto con el firmware original como con RockBox), es a OGG a lo que he convertido mi música. ¡Problema resuelto y con formatos libres!

En agosto se cumplen los años de la creación en AT&T del sistema operativo *nix (perdonad, pero este teclado no tiene la letra “U”). Hasta nuestros amigos de la BBC se hacen eco de ello, por lo que imagino que pronto la red de tubos se llenará de comentarios, artículos, glosas y demás verborreas.

No es casualidad, pero en agosto también se cumplen 40 años de la creación de internet (ya no sabe uno si ponerlo con mayúsculas o no), esa red de tubos que mencionaba antes y que permite, entre otras cosas, que os llegue este texto. Cosas.

Sí es casualidad, pero asistimos igualmente al 18 aniversario de Linux, ese sistema parecido a *nix que un estudiante comenzó a hacer para experimentar, y que se ha acabado convirtiendo en uno de los sistemas que más ha revitalizado panorama *nix (insisto, no siéndolo él mismo).

También parece casualidad, pero recientemente Apple ha publicado una nueva versión de su MacOS 10, certificado también como *nix.

No sé qué es, pero en estos días ha resurgido el conflicto con SCO. Recordémoslo, este SCO no es el mismo SCO que nos trajo su Xenix y posteriormente su *nix, sino que proviene de renombrar a la empresa Caldera, que fue una rama de Novell. Estos chicos pretenden tener los derechos del código original de *nix y quieren que los actuales usuarios de este código paguen por ello. Que se sepa, no han puesto las pruebas sobre la mesa, sino que se las han exigido a los demandados. ¿Juicios 2.0?

En resumen, un mes interesante para los sistemas *nix, y la prueba de que su vigencia (y sus conflictos) van a seguir dando que hablar. Y que escribir.

Durante mucho tiempo, las estaciones de trabajo de Sun han venido de serie (es un decir) con el juego de teclado y ratón de tipo 6: desde las Ultras de los 90 hasta la Blade 2500, pasando por mi fiel Blade 1000. Con la llegada de las nuevas Ultras (20, 25, 40 y 45; sustituidas ahora por las 24 y 27), se incorporó el juego de teclado y ratón tipo 7. ¿Merece la pena el cambio si tenemos los anteriores?

A primera vista, tanto los teclados como los ratones de los tipos 6 y 7 son bastante diferentes. El ratón de tipo 6 es optomecánico (“de bola” me parece oirle a alguien decir), mientras que el de tipo 7 es óptico y con el botón central en forma de rueda. Por su parte, el teclado de tipo 6 tiene una carcasa más curvilínea que el de tipo 7, que parece ser un “homenaje al cuadrado”, si se me permite la referencia a Albers. Adicionalmente, y no por casualidad, tanto el teclado y el ratón de tipo 6 tienen un color gris medio en la parte superior, y púrpura en la inferior (el reposamuñecas desmontable del teclado de tipo 6 es también de este color), al igual que las serigrafías con el imagotipo de Sun. En los nuevos de tipo 7, los únicos colores fundamentales son el gris claro y el blanco, digamos, “marfil” (se acabó el reposamuñecas).

¿Por qué este cambio? Hay varias posibles razones, no todas ellas evidentes ni desconectadas entre sí:

• cambio de estética: las nuevas estaciones de trabajo y servidores no tienen las carcasas frontales de color púrpura y el gris medio ha desaparecido en favor de un gris más claro;
• economía: sin duda, fabricar con menos variedad de materiales (aunque todos sean plásticos) es más barato. Además, la gama de ordenadores actual de Sun tienen menos piezas de plástico en el exterior: por economía y por ecología, según el nuevo mensaje corporativo;
• cambio de imagen: no sólo una cuestión estética o económica, sino también de cómo quieren ser percibidos. ¿Curvas sensuales o rectas racionales? El cambio de mentalidad ha de ser acorde con los tiempos.

Seguramente, estas consideraciones no tendrán demasiado peso a la hora de pensar en el cambio de un juego de teclado y ratón a otro (para mí no lo tuvieron, desde luego; es más: el cambio de estética me molestó un poco). Sin embargo, el hecho de que mi ratón no se moviera siempre con suavidad (acostumbrado al pad del portátil, había olvidado lo que era limpiar los rodillos) me decidió a darle una oportunidad. El juego no es precisamente barato, y el proceso desde que lo pedí hasta que me llegó duró un mes(!), así que durante todo ese tiempo me estuve preguntando si no era mejor haber comprado un ratón con rueda genérico y dejarme de fetichismos de marcas (¡hasta mi alfombrilla de ratón es de Sun!).

Finalmente, llegaron el teclado y el ratón. Lo primero que hice fue intercambiar las teclas de Control y Bloq Mayús. Lo segundo que hice (tras encender el ordenador) fue mover el ratón para comprobar la suavidad: era algo más que suave, era rápido. El ratón de tipo 7 tiene bastante resolución, y basta un poco de uso para acostumbrarse a él. Otra cosa que me llamó la atención del teclado tipo 7 fue la disposición de teclas: las teclas Meta y Alt izquierdas están permutadas de orden y de tamaño; similarmente, las teclas Meta, Compose y Alt Graph están alteradas de orden y tamaño de manera tal que el conjunto es considerablemente más fácil de usar si uno está acostumbrado al teclado de un PC. Es más: en los otros ordenadores que suelo manejar he mapeado las teclas de manera que funcionen igual que en el de Sun.

Si a esto le unimos que el tacto del teclado de tipo 7 es algo mejor que el de tipo 6 (aunque esto sea una preferencia personal), el resultado es que, por una vez, 7 es más que 6. Y muy contento por ello.

Supongamos que tenéis una estación de trabajo (no hace falta que sea una Blade 1000 :) con Solaris 10. Supongamos que queréis imprimir con vuestra fiel HP1022. Supongamos que la mejor opción es CUPS (el venerable lpr no tiene tantas configuraciones de impresoras, y CUPS funciona en red). ¿Cómo proceder? Sencillo.

Primero, vamos al disco “Solaris Companion”, sólo para descubrir que debido a una incompatibilidad con la licencia del Berkeley DB, han dejado de incluirlo :(

Después nos vamos a Blastwave (se supone que lo tenemos ya debidamente configurado) y averiguamos que tienen empaquetado CUPS 1.3.10. Nos lo traemos con todas sus dependencias, lo arrancamos y vemos que da más errores de los debidos.

Nos tiramos de los pelos (o no) y a continuación leemos en los foros que hay que cambiar el usuario y el grupo con el que arranca el programa en /opt/csw/etc/cups/cupsd.conf:

User nobody
Group nobody


Arrancamos de nuevo CUPS y vemos que tampoco era eso. El error es que le faltan algunos directorios y que no puede leer el fichero de configuración. Copiamos el fichero a /tmp y forzamos a cupsd a leerlo de allí. Ni por esas.

Entonces llega el encantamiento correcto:

for dir in cache etc log run spool; do
mkdir -p /opt/csw/var/$dir/cups
done


Arrancamos, y está hecho :)

Ahora, sólo falta llevar nuestro navegador a http://localhost:631/ y configurar la impresora a nuestro gusto.

A veces porque es necesario, a veces porque es obligatorio, el cambio es una constante de la vida. *nix pro se renueva porque estaba en los planes (como otras de mis páginas), pero sobre todo porque mi proveedor de alojamiento ha hecho unos cambios que me obligan a acelerar el paso a otro sistema de publicación de contenidos. Buen servicio y unas cuantas horas de diversión me proporcionó el anterior, que yo mismo creé. Este nuevo me permitirá publicar con más facilidad, al tiempo que abre una era para los comentarios (¡sed juiciosos, o al menos jocosos!).

Al margen de la forma (que aún está por terminar), el fondo de *nix pro también cambia para ser más él mismo. No habrá una orientación hacia un tema concreto (como en su momento propuse), al tiempo que trataré de dejarme menos historias en el tintero. En otras palabras, será más una expresión de lo que reza en el subtítulo de este diario, confesiones de un administrador de sistemas *nix.

Gracias por vuestra atención.

Bienvenidos a *nix pro: confesiones de un administrador de sistemas *nix. Aquí encontraréis artículos sobre el mundo de los sistemas operativos *nix, derivados y similares de aquel conocido sistema desarrollado originalmente por AT&T, y escrito con la habitual sintaxis elusiva de patentes y marcas. Y, por supuesto, alguna anécdota sobre mi experiencia personal de más de 10 años como Administrador de Sistemas Linux y Solaris.

¿Por qué lo llaman *nix cuando quieren decir… ya sabéis qué? Buena pregunta. Supongo que lo que comenzó como un intento de no infringir una conocida marca registrada, se ha convertido en parte de la cultura de los hackers (no confundir con crackers) del sistema.

En estas páginas trataré de contar las cosas que me parecen interesantes, no sólo desde el punto de vista técnico, sino también histórico y personal. Para ello, utilizaré diversos apartados denominados de la siguiente forma:

kernel

Cuestiones importantes. Por ejemplo: seguridad y noticias de cierta trascendencia.

platform

Ordenadores. Tanto sistemas comerciales predefinidos como ampliaciones, mejoras o consideraciones de hardware.

system

Sistemas *nix. Artículos sobre sistemas *nix concretos.

lost+found

Anécdotas memorables (o no tanto). Cosas que ocurren en el mundo real.

etc

Un poco de todo. Aquí van, como no podía ser de otra forma, las cosas que no tienen cabida en el resto de secciones.