Leía no hace mucho en una revista dedicada al mundo del pc, que dedicaba un extenso artículo a Linux, que existen en torno a él una serie de "leyendas urbanas", y citaba una serie de ellas.
En este momento creo disponer del "poso" suficiente de conocimientos, después de una prueba mínima de tres distribuciones, para opinar sobre dichas "leyendas urbanas"; lo que sigue debe tomarse como lo que es: la opinión de un usuario "de a pie" que se acerca a Linux sin conocimientos previos, o con ellos muy limitados.
Por esta razón, no intentaré discutir ningún razonamiento técnico que explique por qué las cosas son así en Linux y no pueden ser de otra manera.
No, el usuario "de a pie" no tiene por qué entender esos razonamientos, ni le importan. El usuario "de a pie" quiere una máquina (probablemente a muchos se les escape el significado de las palabras "Sistema Operativo") con la que pueda trabajar desde el principio, con el mínimo posible de conocimientos previos.
"Linux es algo hecho por técnicos para técnicos".
Lamentablemente, debo apoyar la afirmación. Y me baso en varias razones fundamentales:
- El continuo recurso a la consola o terminal para poder realizar acciones triviales, como puede ser la instalación de una aplicación. Ello exige del usuario el conocimiento previo, al menos, de un conjunto básico de comandos y sus parámetros y modificadores. Esto está pensado por y para técnicos, no para gente corriente.
- El sistema de división en paquetes de los módulos y aplicaciones, y la dificultad de su identificación y comprensión. El usuario "de a pie" se ve confundido, desorientado y sobrepasado con los paquetes y sus dependencias. Él sabe de funcionalidades: quiere instalar una aplicación de fax, pongamos por caso, y no sabe (ni debería por qué tener que saber) qué paquetes, con sus dependencias correspondientes, debe instalar para conseguir lo que quiere. Eso, debería resolverlo por él el Sistema Operativo.
- Las diferencias entre las distintas distribuciones. Por poner un ejemplo, algunas admiten los paquetes en formato .rpm o .deb, pero no todas. Ciertas distribuciones colocan determinados archivos en una carpeta, mientras que otras distribuciones eligen otra diferente. El usuario sin conocimientos profundos se siente confundido ante instrucciones de instalación, por poner un caso corriente, del estilo... si la distribución es "A", entonces tendrá que crear la carpeta... Pero si es "B", la carpeta será...
- La incorrecta, parcial o inexistente traducción al castellano de aplicaciones y ayuda. Hay quienes pensamos que constituye una desgracia el poco conocimiento de idiomas de los españoles en general, pero es un hecho; esto añade en muchos casos un plus de dificultad a la hora de "hacerse" con una distribución. E incluso otros, entre los que me cuento, no tenemos ese problema o nos afecta en grado mínimo, pero queremos ver TODO en español en nuestra máquina, sin que la comprensión de un texto de ayuda en inglés nos suponga un plus de esfuerzo, pongo por caso.
- La pérdida de control sobre el espacio de su disco duro. El particionado de Linux es un verdadero arcano para el no iniciado, que hará muy bien en permitir que el procedimiento de instalación lo haga por él. Pero... no hay una representación gráfica en los "n" navegadores de archivos de Linux de esa distribución física del espacio del disco duro, con lo que el usuario novel puede estarse quedando sin espacio en "/hdxx", pero tener "/hdxx" vacío, y no tiene medio de saberlo. Y como se le ocurra la malhadada idea de cambiar eso sin conocer sus consecuencias, se puede encontrar en serios problemas. Diré algo más: "/hda1" es algo críptico para el usuario de a pie, así como los nombres de carpetas: /etc, /bin, /home… El utilizaría nombres como "Datos" o "Sistema", y solo así sabría de qué está hablando, y para qué se utiliza. Esto es otro ejemplo arquetípico de algo hecho por técnicos para técnicos.
Hablando de espacio en disco: tropecé por casualidad en Ubuntu 7.04 con una curiosa utilidad, el "Analizador de uso de disco":
No dudo ni por un momento que a un técnico esta montaña de datos le debe ser de gran utilidad. Pero no responde de forma clara y sencilla a las preguntas de un neófito:
- ¿En cuántas particiones está dividido mi disco físico?
- ¿Qué espacio tiene asignado cada una de ellas?
- Y de este espacio asignado, ¿qué parte está libre?
- ¿En cuál de estas particiones reside mi carpeta personal?
Ya sé: para un iniciado estas preguntas son estúpidas. Pero cuando un principiante quiere respuestas, se encuentra con cosas como esta:
http://xinfo.sourceforge.net/documentacion.php?ver=particiones
...que no sé si informan o confunden aún más.
Aparte del anterior, ejemplos de muchas de estas cosas los hay "a patadas" en mis anteriores post. Voy a refrescaros la memoria con uno de ellos, que me trajo por la calle de la amargura:
Salvo en Ubuntu 7.04, la instalación de la aplicación "Vmware Tools", necesaria para mi infraestructura de pruebas, ha constituido un verdadero calvario, y su ausencia me ha complicado la vida extraordinariamente.
Llegaba a un punto en el que la consola me informaba de que no existía determinada carpeta donde el procedimiento de instalación esperaba encontrar las "fuentes" del kernel, y me daba la opción de indicar la ruta o "path" correspondiente. Y obviamente, perdí mucho tiempo intentando averiguar dónde se habían ubicado en esa distribución concreta.
Bien, cuando me sucedió esto con Mandriva 2007 Spring, después de otro tropezón idéntico con Open Suse 10.02, me puse seriamente a tratar de solucionarlo, y tras echarle tiempo de investigación, descubrí que la carpeta no existía... porque no tenía instaladas las dichosas "fuentes" del kernel.
Quizá para conocedores esto sea de lo más evidente, pero yo soy un usuario "de a pie".La instalación de esas "fuentes" constituyó el mejor (peor) ejemplo de lo que estaba diciendo: busqué "kernel" en el "Instalador de software" (como quiera que se llame) y aparecieron una serie de paquetes cuya finalidad no podía casi ni adivinar, con la explicación de los mismos… en inglés. Finalmente, había dos paquetes que aparentemente eran lo que necesitaba. Pero, ¿cuál? ¿O quizá ambos? ¿U otro que no había visto y que incluso podía no llevar "kernel" en su nombre?
Pregunta dirigida a los conocedores de Linux: ¿os parece medio normal siquiera, que un usuario "de a pie" tenga que pasar por todo esto para instalar una aplicación? Diría más aún: ¿creéis que es lógico que para instalar una aplicación haya que compilarla con el kernel concreto? Y, por lo que he visto en la Red, hay muchas aplicaciones que deben instalarse de este modo.
Y ahora, de seguro podríais darme mil y una razones técnicas, entre otras posiblemente que así consume menos recursos y es más eficiente y rápido... Las acepto todas, pero yo estoy hablando de algo distinto.
De lo que estoy hablando, es de que todas esas particularidades deben ser transparentes para el usuario "de a pie", y son los desarrolladores de kernel y paquetes quienes tendrían que hacer lo necesario para que todo esto funcionara con la mínima intervención del usuario, que idealmente solo tendría que hacer doble click, en no importa qué distribución o escritorio, sobre el icono, con no importa qué extensión, o sin ella, que representa un archivo, para que la aplicación correspondiente se instalara.
En el extremo, y ya que resulta tan imprescindible disponer de las susodichas "fuentes", instalarlas desde el principio con la distribución, para evitar problemas al usuario. Se ocupa un poco más de disco, pero vale mucho más en mi opinión el tiempo, el esfuerzo y la frustración que se siente ante lo que no puedo calificar sino como un despropósito.
Otro botón de muestra: cuando comencé a darme de cabezazos contra la configuración de Samba, suspiraba por disponer de una aplicación gráfica que me permitiera realizar los cambios precisos.
No soy yo únicamente el que tiene serios problemas con ello. Buscar en Google "configurar samba", y encontraréis 714.000 referencias "aproximadamente".
Finalmente, encontré una de esas aplicaciones: se llama GSAMBAD, y la descubrí cuando estaba probando la distribución Ubuntu 7.10.
Claro que... Mi concepción de “aplicación gráfica” es otra, influida en mi ignorancia sobre Linux por el concepto “asistente” en Windows. Y GSAMBAD no es un “asistente”. Un par de imágenes valen más que mil palabras:
¿Qué estamos viendo? Una aplicación que no resuelve la complejidad de la configuración de Samba, sino que se limita a poner cuadros de texto para cada uno de los parámetros posibles. Y quizá (no lo sé) incluso puede que realice una mínima verificación de lo que se escribe. ¡Para ese viaje, no se precisan alforjas!
Lo que se necesita es una aplicación que, mediante preguntas simples que el usuario de a pie sepa responder, vaya modificando internamente los diferentes parámetros del archivo smb.conf. Y con explicaciones claras y sencillas en las diferentes ventanas, no en la ayuda, sobre el significado de cada uno de los datos y sus posibles valores.
¿Que probablemente un “asistente” así sería inviable para plasmar en él todas y cada una de las complejidades de Samba?
Cierto. Pero mirad en los foros como yo he hecho: lo que un "usuario de a pie" quiere hacer es montar una pequeña red local, puede que con alguna máquina Windows (o no) para compartir entre ellas datos y posiblemente una impresora. A esto es a lo que debería dar respuesta. Y para el resto de posibilidades, solo al alcance de técnicos con profundos conocimientos de comunicaciones, está la edición a mano de smb.conf.
Pero... no he visto cosas así en Linux. Solo consola y más consola, y esfuerzos muy loables de técnicos que saben muchísimo de Linux, para dar aspecto gráfico... a los mismos parámetros que se pueden escribir sencillamente mediante un procesador de textos.
De nuevo, algo hecho por técnicos (que no tienen en mente al hacerlo al usuario "de a pie") y por ello, para técnicos.
Y, ya que hablo de smb.conf. Si lanzas un editor de textos desde el menú, te encontrarás con la desagradable sorpresa de que no te permite modificarlo. Yo lo tuve muy claro: abrí una consola, en ella sesión como superusuario, y lancé “a pelo”, por su nombre, el editor.
Veamos: hay un archivo que debe modificarse para adaptarlo. ¿Por qué, en lugar de impedírseme y obligarme a dar un rodeo (que como siempre, pasa por la consola) no se me advierte simplemente mediante un mensaje de que pretendo hacer algo que comporta cierto riesgo, y se me permite aceptar o cancelar la edición?
De veras, me pongo en los zapatos de un usuario sin conocimientos, y probablemente habría tenido que desistir en ese punto.
Podría seguir, pero lo dejo aquí por ahora.
