Estos últimos días he recibido una verdadera avalancha de comentarios. Dejar un nuevo comentario como respuesta (lo he hecho en muchos casos) no permite, por la propia naturaleza del medio, explicar algunas cosas con cierta extensión, ni ilustrar las explicaciones con imágenes.
Por ello, y aún a riesgo de que algunas o algunos de los que habéis tenido la amabilidad de dejarme un comentario no leáis este "post", me he decidido a escribirlo.
Han sido varios los temas tratados, y procuraré dar respuesta al menos a los más importantes.
Los gestores de paquetes, y la instalación de software en general.
En mis pruebas de las varias distribuciones de Linux, he echado en falta un estándar único. Se me ha tratado de decir en tono didáctico (lo agradezco) que algunas distribuciones apuestan por el formato .rpm, otras por .deb y finalmente, que los archivos .tar.gz son aceptados por todas ellas. Bien, esto es algo que aprendí muy pronto, cuando intenté instalar una aplicación en Ubuntu 7.04 que presentaba los formatos .rpm y .tar.gz; pero aprenderlo me costó tiempo de navegación por los foros. ¿Habría encontrado información al respecto en la ayuda de la distribución? Es posible, pero... lo voy a dejar aquí, porque pienso dedicar un apartado a este tema.
Por fin, están los gestores de paquetes, y el recurso al mandato apt-get, a los que me referiré más adelante.
Con esto, el tema no queda resuelto en absoluto. Si tienes una aplicación que se instala mediante un paquete en formato .rpm, y tu distribución no la contempla, ¿qué haces?
Y aún dentro de un archivo comprimido .tar.gz soportado por todas, cada desarrollador hace un poco de su capa un sayo. Así, algunas de estas aplicaciones se instalan mediante sucesivos mandatos make, configure e install, pero no todas. En concreto, instalar la aplicación Vmware Tools (contenida en un CD) precisa que se ejecute un archivo con extensión .pl después de descomprimir el .tar.gz original.
En general, cuando me enfrenté por primera vez con el problema, aprendí que es muy importante buscar entre los archivos descomprimidos alguno que contenga las instrucciones necesarias para ese paquete en concreto. Solo que... no siempre existe, ni su nombre tiene por qué ser lo suficientemente claro como para reconocerlo a simple vista ni, cuando lo encuentras, sus instrucciones son necesariamente accesibles para el usuario no experto.
Y como una gran parte de los comentarios versan precisamente sobre la instalación de este paquete, voy a responder a las sugerencias del mejor modo posible: mediante ilustraciones.
Utilizaré para ello la distribución Ubuntu 7.10, de la que aún conservo la máquina virtual.
En primer lugar, intentaré utilizar el gestor de paquetes. Busco "vmware"...
...y el único paquete que me ofrece es vmware-player. Esta es una aplicación que permite correr en un equipo una máquina virtual, aunque no crearla, nada que ver con las "vmware tools". De todas formas, la leyenda me advierte que
"...VMware Player no puede instalarse en un equipo como el suyo (i386). O bien la aplicación requiere funciones hardware especiales, o bien el vendedor ha decidido no soportar equipos del mismo tipo que el suyo".
Esto no es cierto, o al menos no lo es en Windows, donde podría correr perfectamente la versión correspondiente en mi máquina, pero es algo que no hace al caso.
Lo intento ahora mediante apt-get:
sudo apt-get install vmware-tools
[sudo] password for ap:
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
Leyendo la información de estado... Hecho
E: No se pudo encontrar el paquete vmware-tools
NOTA: El amigo que incluyó el comentario escribió "apt-get vmware-server", que no tiene nada que ver con la que estaba intentando instalar.
(Por cierto: ¿por qué alguien cree que es más sencillo abrir una consola y enredarse con mandatos, cuando basta con hacer doble click sobre un icono? O no he comprendido lo que quería decir o, aunque me lo expliquen, no podré nunca entenderlo)
Yo ya sabía antes de comenzar que nada de esto funcionaría. ¿Por qué lo he hecho entonces? Porque -a veces de forma nada sutil- he sido tratado de ignorante por algunos, o al menos he creído percibir cierta condescendencia cuando me indicaban, puede que en ocasiones con la mejor voluntad, cómo se debe hacer en su opinión.
No voy a devolver ningún calificativo y agradezco las lecciones de buena fe, pero pediría un poco de humildad, porque son algunos de los que han dejado esos comentarios quienes están hablando sin conocer la aplicación que trato de instalar. Es una aplicación que no tiene nada que ver con Linux sino con mi entorno de pruebas, se distribuye en un CD, por lo que el instalador de paquetes no la conoce, y se instala ejecutando el archivo vmware-install.pl contenido en el .tar.gz.
Pero estaba hablando de la, a mi juicio, necesidad de un estándar universalmente aceptado en Linux para la instalación de aplicaciones que no estén incluidas en el montaje de repositorios e instaladores de paquetes.
No sé si ese estándar debe ser .rpm, .deb o .loquesea, pero debe consistir en un archivo ejecutable, sobre el que baste con hacer doble click para que se desencadenen todos los procesos necesarios. Y que todos los desarrolladores se olviden de install, apt-get, .tar.gz, y de sus formatos solo contemplados en una distribución concreta, y utilicen en exclusiva ese único procedimiento de instalación, en no importa qué distribución ni con qué escritorio.
Hablando de los actualizadores de paquetes, la situación actual es como mínimo confusa, y en nada ayudan cosas como esta, que también describí en su momento:
¿Qué vemos aquí? Que buscando "beryl" en el instalador de paquetes, el resultado es "no hay ninguna aplicación disponible...". Si la búsqueda es "compiz", obtengo dos paquetes: "Advanced Desktop Effects Settings (cssm)" y "MacSlow's Cairo-clock" y ninguno de ellos (salvo que esté muy equivocado) instalará Compiz-Fusion.
¿Cómo se instala? Mediante el recurso a los foros, encontré la solución en páginas cómo ésta:
sudo apt-get install compiz-core libdecoration0 compiz compizconfig-settings-manager compiz-kde emerald emerald-themes
Esto funcionó en mi prueba real con Kubuntu 7.10 sin agregar ningún repositorio, y entonces me pregunté (y aún sigo en la duda) por qué el instalador de paquetes no lo muestra en una búsqueda, pero haciendo uso de la consola se baja e instala (con toda la ristra de paquetes relacionados y sus dependencias)
Alguien me dijo en tono ofendido que "...Synaptics funciona perfectamente", y yo no lo he dudado nunca. Lo que sí estoy poniendo en cuestión es que ese "perfecto funcionamiento" sea el adecuado para alguien que, como yo, se acerca a Linux sin demasiados conocimientos previos. A las pruebas me remito.
Consola vs entorno gráfico.
Casi podría escribir un "post" entero solo con esto, de manera que trataré de resumir.
Rescato de un comentario: "...tienes que configurar las X...". Venía a cuento de mis dificultades con Kubuntu 7.10 sobre una máquina real, con una tarjeta ATI Radeon 9550 256 Mb, para eliminar una especie de bandas negras que aparecían en el monitor durante unas décimas de segundo, que resultaban de lo más molesto.
Le respondía con otra pregunta: ¿Dónde están las "X" (lo que quiera que sea eso)? ¿Se trata de una opción de menú, o por el contrario, es un paquete que debo saber previamente que existe, y cuyo nombre debo conocer, e instalar a golpe de "sudos" y "apt-gets"?
Más recientemente, alguien argüía en su comentario que "...tú también tuviste que aprender a lidiar con el panel de control en Windows..." (la cita no es literal, pero ese es el sentido)
Bien, efectivamente tuve que aprender la función de las distintas opciones del panel de control cuando apareció (creo recordar que ya en Windows 95) Y las de su equivalente en OS/2 de IBM. Y...
Pero existe una gran diferencia: en mi concepto, el panel de control, o su equivalente, en un sistema gráfico debe contener todas las opciones necesarias para configurar las "X" (sigo sin saber qué cosa son) y cualquier otra opción configurable por el usuario.
Y en Windows, hacerte una idea al menos de su función y significado es tan simple como hacer doble click sobre una de ellas, y revisar el contenido de las distintas pestañas y opciones. ¿Que esto no está tampoco al alcance de muchos usuarios? De acuerdo, no lo voy a discutir. ¿Que si tocas algo "a tontas y a locas" puedes hasta quedarte sin Sistema? Por supuesto, ya sé de alguien que consiguió cambiar (aún me pregunto cómo) la tasa de refresco de su monitor por otra que no soportaba... y se quedó con él en negro. Pero al menos tienes una forma sencilla y amigable de cambiar lo que necesites o desees.
Lo que me he encontrado en Linux, por el contrario, son cosas cómo ésta:
¿Qué estamos viendo? Una opción de configuración de la tarjeta ATI a que me refería con dos únicas opciones deshabilitadas, sin ninguna posibilidad en apariencia de actuar sobre nada. Y cuando lo muestro en el blog, y describo mi frustración ante ello, alguien me tacha implícitamente de ignorante, porque "debería saber que tengo que configurar las X".
Repito la pregunta, de otra forma: ¿Os parece normal que un usuario con pocos conocimientos de Linux tenga que saber por ciencia infusa (o perdiendo horas en los foros) que existe algo llamado "las X", qué cosa son, y qué mandatos de consola debe emplear para configurarlas, o qué paquetes debe instalar para ello?
Mantengo mi opinión: TODO lo necesario para configurar un Sistema Operativo, cualquier Sistema Operativo, debe estar plasmado en una opción de menú, y disponer de un entorno gráfico para su manejo. Cualquier otro procedimiento constituye una dificultad, la mayor parte de las veces insalvable, para un usuario novel.
Y, para que se me entienda bien, no estoy hablando ahora del conocimiento previo de los mandatos básicos de la consola (también opino que ese conocimiento no debería ser necesario) sino de algo más, y muy importante:
Cuando, como en Linux, se prima el uso de mandatos de consola y sus parámetros u otros procedimientos no evidentes e inaccesibles sin un profundo conocimiento del sistema, en lugar de sustituirlos por opciones de menú que dan paso a ventanas gráficas de uso amigable y autoexplicativo, se consigue hacer huir de algo así a muchos usuarios, y decantarse por otra cosa que no le cree esos problemas. Y no importa lo "bueno" y "seguro" que sea lo que no entiende y no es capaz de configurar: aunque la alternativa fuera peor (y de nuevo afirmo que no lo es) al menos se trata de algo pensado para el usuario sin demasiados conocimientos, no exclusivamente para el experto y el técnico.
Si los entusiastas del software libre y Linux queréis que algún día sea una alternativa extendida (lo que me encantaría, dicho sea de paso) debe resolverse ese enfrentamiento a que me refería en el título:
Consola vs entorno gráfico
Seguridad, antivirus y cortafuegos
Algún que otro comentario decía que "...en Windows tienes que contar con antivirus, antitroyanos y firewall..." (de nuevo, la cita no es literal)
Se dice también que el kernel de Linux está libre de errores. Recuerdo a este respecto a alguien que me aportó un "ingenioso" nombre para Windows: "Guinbugs".
Mira por dónde, este último comentario lo leí el domingo, y el lunes tenía en mi correo un mensaje de Panda Labs conteniendo, entre otras, la noticia de que se había descubierto en el kernel de Linux una nueva vulnerabilidad, y no es la primera vez que tengo noticias al respecto.
Voy a tratar de dejar las cosas en su lugar, pero primero, permitidme una afirmación contrastada: la mayoría del malware en los últimos tiempos no persigue el (dudoso) honor de haber infectado más ordenadores que nadie, como en los primeros y heroicos tiempos, sino que su propósito es el de conseguir un beneficio económico, bien mediante la obtención de millones de direcciones de correo a las que dirigir "spam" (he leído que hay un floreciente mercado negro en el que se compran) o, más directamente, hacerse con números de tarjetas de crédito o identificadores y contraseñas de acceso a páginas web bancarias.
Aquí funciona lo de los grandes números: ¿para qué me voy a tomar el trabajo (dirán para sí los creadores de malware) de escribir y probar uno de estos virus para apenas un 3% del parque de ordenadores que corren Linux, cuando tengo a mi disposición más de un 90% (literalmente decenas de millones de máquinas) con Windows?
Y es que en esto, las cosas funcionan del siguiente modo: alguien envía diez millones de mensajes del estilo "la información importante para el Cliente del Banco X", o también "Enhorabuena, usted ha ganado un premio de la Lotería española" (o británica) a sabiendas de que solo encontrarán a diez o doce incautos que piquen. Si las víctimas potenciales fueran únicamente 1.000, posiblemente no obtendrían ninguna respuesta. Es un ejemplo sencillo, que tiene que ver con el spam, no con técnicas sofisticadas como el "keylog" o la creación de redes de ordenadores "zombies" (que sí deben ser específicas para un Sistema Operativo en particular) pero que me vale por lo clarito y concreto.
De manera que es probable que la supuesta inmunización de Linux o incluso Mac contra el malware, tenga más que ver con su poca implantación que con otra cosa.
Pero es que, como también dije en una respuesta, resulta que existen antivirus para Linux. No me he calentado demasiado la cabeza: una búsqueda de "antivirus" en la pestaña Linux de Softonic, da como resultado 17 soluciones, alguna de ellas de pago, y con versiones de especialistas en el tema como BitDefender, Kaspersky, McAffee y Panda Security.
La pregunta es: si Linux es un Sistema tan seguro, robusto e inmune a los virus como se lee, ¿por qué éstas que he citado y otras compañías han creado versiones Linux de sus productos antivirus?. (¿No será que...?)
Personalmente, si mi sistema operativo fuera Linux o Mac, tampoco estaría tranquilo sin disponer de un cortafuegos bien configurado (ya sé: las distribuciones de Linux lo traen; otra cosa es que la gente lo utilice) y un antivirus que se actualice muy frecuentemente de forma automática.
Y quienes creáis que en Linux no es necesario porque lo dicen en los foros, pues... allá vosotros.
Capítulo aparte merece el montaje de usuarios, superusuario y contraseñas de Linux en general.
Veamos: resulta que un usuario "normal" no puede hacer prácticamente nada. No puede modificar la configuración. No se le permite instalar un programa... pero cada vez que lo intenta, se le pide que introduzca la contraseña propia, y ya. Ahora puede hacerlo todo.
Para introducir aún más confusión (y que esto resulte todavía más absurdo, dicho sea de paso) algunas distribuciones no te solicitan en la instalación la contraseña de superusuario. Pero si tienes -como yo- la paciencia de bucear en los menús de configuración, encontrarás una ventana en la cual puedes asignar o cambiar esa contraseña.
Para más inri, en una de las distribuciones que he probado el mandato "sudo" no existe de entrada, salvo que instales a posteriori el correspondiente paquete.
El resultado es que, cuando estás instalando y configurando el sistema, te encuentras en la necesidad de estar introduciendo tu contraseña a un ritmo de una vez cada dos minutos, aproximadamente.
¿Os parece que todo esto incrementa la seguridad, o simplemente -es mi opinión- constituye más una molestia que otra cosa?
Y no digo más. Que cada uno saque las conclusiones que estime oportunas.
Una última cosa, volviendo a lo del "bug": suponiendo (y es mucho suponer) que el parche del kernel de Linux para solucionar la vulnerabilidad citada esté disponible mañana mismo, ¿cuándo y por qué medios llegará a los usuarios? En Windows la respuesta es clara y conocida. ¿ Y en Linux? Os dejo la pregunta como tema de reflexión.
La ayuda en Linux.
En este camino, me he encontrado casi de todo (y no siempre bueno) en lo tocante a la ayuda. Hubo una distribución, cuyo nombre he querido olvidar, en la que estaba mayormente escrita en inglés.
Pero lo que ha sido un lugar común es la, en ocasiones, absoluta inoperancia de la opción de búsqueda, que sigo preguntándome para qué existe, si no da resultados.
Repito mis ejemplos de un post anterior. Se refieren a Kubuntu 7.10:
En el primero de los casos, escribí "teclado usb". En el segundo "ratón". Y las dos veces no me ofreció resultado alguno.
Vamos, que no buscaba "xghwyz", sino dos términos que SÍ aparecen en diferentes capítulos de la ayuda. ¿Entonces?
¿Quizá es que debí instalar algún paquete que en mi ignorancia no conozco? No lo sé. Os lo dejo ahí.
Los drivers.
Fuente de disgustos para mí, y causa de muchos comentarios.
Bien, en el post "Linux y los fabricantes..." hablaba como ejemplo de una Empresa que se enfrenta a la escritura de drivers para Linux, y en lugar de elegir cualquier otra clase de hardware, me "salió" que en fuera un fabricante de tarjetas gráficas.
Podía haber hablado, qué sé yo, de alguna que se dedicara a tabletas digitalizadoras o tarjetas de sonido, pero elegí ése. Y puede que como ejemplo no haya sido demasiado feliz, porque si en Linux hay algún hardware con cierto soporte (con sus matices) ese es precisamente las tarjetas gráficas.
Pero bien, debo decir que, cuando tuve problemas en Kubuntu 7.10 con mi ATI Radeon 9800 256 Mb., al primer sitio que recurrí fue a la página Web del Fabricante, y allí encontré drivers para ella aunque, como la felicidad nunca es completa, la explicación en la página de descargas decía que era para "X.Org 6.7, 6.8, 6.9, 7.0, 7.1, 7.2, 7.3".
De modo que me entró la risa floja y ahí acabó el intento, porque no sé, y saberlo me habría llevado probablemente horas, qué cosa es "X.Org", y si la versión que tenía instalada (o no, que tampoco lo sé) es alguna de las de la lista.
(Por cierto: ¿será esto "las X" de las que hablaba más arriba?)
Lo que sí he leído es -siguiendo con el tema de las tarjetas gráficas- mucha información (incomprensible para mí) acerca de algo llamado "drivers libres", en contraposición a otra cosa denominada "drivers propietarios".
Y lo que sé, y nadie puede discutirme, es que mi lector de tarjetas no fue reconocido en la instalación de Kubuntu 7.10.
Y que mi conjunto de teclado y ratón Logitech no funcionaba adecuadamente: se "colgaba" con demasiada frecuencia, impidiéndome utilizar la máquina, que debía apagar "a las bravas".
Y que cuando encontré alguna información al respecto, fue que "hay un problema de permisos (?) con los productos de Logitech".
De manera que no retrocedo ni un punto así en mi afirmación de que Linux (y sus circunstancias, y sus muchas veces incomprensibles métodos y conceptos para el profano) tiene un "agujero" de tamaño abismal en todo lo relacionado con los drivers.
¿Cómo debe, en mi modesto saber y entender, funcionar todo esto, para que un usuario sin demasiados conocimientos como yo, no se enfrente a una montaña a la menor?
Para el hardware con soporte: que éste sea completo, sin historietas de permisos (?) con los ratones de Logitech, ni de drivers propietarios o mediopensionistas.
Para el que no lo tenga: lista de hardware soportado, y si el tuyo no está en ella... pues tú mismo: o te compras otro que sí lo esté, o te olvidas de Linux (que fue mi opción)
Y en todos los casos, que TODO el hardware se configure mediante una opción de menú, en un entorno gráfico clarito y comprensible. Y si es necesario que exista X.Org o lo que sea, que se instale de entrada con la distribución.
Porque si, cuando tuve que cambiar la tarjeta gráfica, me hubiera enredado en Windows con complicaciones de este estilo, probablemente habría tenido que recurrir a un servicio técnico.
Y no fue el caso.
Escribir entradas en este blog.
Esto no tiene nada que ver con Linux, Windows o Mac (bueno, con Windows sí, indirectamente)
Si leéis mis primeras entradas, y luego miráis estas últimas, quizá os daréis cuenta de que la calidad ha mejorado sensiblemente. Con los primeros "post" las he pasado "canutas", he perdido horas y horas de mi tiempo inútilmente, y me pide el cuerpo decir algo al respecto:
Al procedimiento WYSIWYG de Blogger le queda mucho camino por recorrer para ser una opción minimamente utilizable (soy muy caritativo al decirlo así) En un momento determinado, tuve que optar por escribir código HTML "a pelo", pero aún así, insertar una imagen es un número de circo: el párrafo HTML se va al principio, y tienes que cortar y pegar, previa búsqueda del lugar exacto donde querías introducirla. Y esto es así tanto si utilizas el editor WYSIWYG como si escribes a base de etiquetas HTML.
Bien, pues hace un par de semanas descubrí un producto gratuito de Microsoft: Windows Live Writer. Ahora escribo mis blogs desde una ventana en mi máquina, sin acceder siquiera a la página de Blogger. Tengo la mayoría de las facilidades de un editor de texto, incluido el control completo del aspecto, tamaño y color de la fuente, posibilidad ("de verdad") de incluir listas numeradas o con viñetas, e insertar una imagen donde yo quiero es tan simple como colocar el cursor, y después utilizar la opción de menú "Insertar/Imagen". También, comprobación ortográfica "sobre la marcha". E incluso me permite definir varias cuentas con distintas páginas de alojamiento de "blogs".
Hay un botón para publicar la entrada directamente, sin entrar en la página, y hasta el aspecto de la ventana de escritura es similar al de mi blog.
Os lo recomiendo, aunque... lo siento, no existe versión para Linux, que yo sepa.
