Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
La estabilidad a largo plazo

jamarier's Diary
Por jamarier
departamento Mantenimiento y administración de linux , Sección Diarios
Puesto a las Mon Oct 31st, 2005 at 03:07:24 PM CET

Este fin de semana me ha tocado hacer un poco de administración en mi equipo. De nuevo me he quedado sin espacio en el disco duro. Aprovechando que limpiaba por aquí y limpiaba por alla, he actualizado el kernel.

Como siempre que ocurre este evento (y que suelo intentar aplazar bastantes veces), mi módulo específico para mi nvidia se van al garete. Ya no me asusto cuando tras instalar el kernel se vuelve todo a negro con letritas blancas.

Tras intentar recompilar para mi debian los dichosos modulos/drivers (por si no lo sabeis: «module-assistant prepare && module-assinstant auto-install nvidia» y todo automático no como antes) he tenido que meter mano a directorios en los que últimamente no entro (por ejemplo /etc/) y me he encontrado una cantidad de basura increible.

Y aquí es el punto de entrada a mi pensamiento sobre la estabilidad a largo plazo.

 


Desde que me compré la túnica naranja y me convertí a la religión única. No he tenido necesidad de formatear el disco duro ni reinstalar el sistema operativo. Son ya varios años (unos cinco diría yo) de luchar contra configuraciones e historias. A partir de ahora voy a hacer mención exclusivamente a mi distro «la gran verdad»; entiendo que las demás proveen pobres imitaciones a todos los comportamientos que voy a describir. Hablando en serio y para no levantar suspicacias, creo que uno de los puntos interesantes de esta historia es la discusión de cómo se resuelven estos problemas en distintas distribuciones (y yo hablaré desde la que conozco).

A priori, las distribuciones tienen mecanismos de «destrucción de lo inutil». Te facilitan instalar programas: «apt-get install fulanito», te facilitan la desinstalación de programas: «apt-get remove fulanito» y hasta la elimininación de los ficheros de configuración que generaron: «apt-get --purge remove fulanito». Si bien es un avance inconmensurable el que sea la utilidad y no uno el que se encargue de buscar el programa de internet, bajarlo, instalarlo y dar una configuración inicial que sea usable, la desinstalación no está tan avanzada como nos han hecho creer.

  1. No siempre se borran las librerías que se instalaron automáticamente desinstalar el programa que las necesitaba. Aunque la utilidad aptitude lleva cuenta de las instalaciones automáticas (solo las que se instalaron desde aptitude). No siempre funciona. Ignoro si es porque hay referencias circulares o lo que sea, pero es muy habitual al instalar un paquete nuevo que se autoinstalen 5 librerías y al desinstalarlo que se desinstalen 3.

    existen utilidades como deborphan u orphaner para ayudar a desinstalar librerías no usadas. A mí no me resultan muy eficientes.

  2. Las configuraciones personales se almacenan en archivos y directorios ocultos que parten del home de cada usuario. Las utilidades son muy libres de crear los ficheros/directorios que necesiten pero estos nunca son borrados (es un comportamiento muy conservador). la conclusión es que desde la última limpieza que efectué tengo actualmente 495 ficheros de estas características (solo colgando de ~ no incluyo los que entran dentro de .gnome o .kde) y algunos de ellos con nombres tan sonoros como «.ZTaJrd»

    ¿Cómo se gestiona eso? Al final son ficheros de poco tamaño y yo personalmente tiendo a ignorarlos, dejando que se dispersen, que crezcan y hasta se reproduzcan si son felices. Todo por no borrar una configuración de un programa que cuando dentro de 2 meses lo necesite esté como debe de estar.

  3. Igualmente la configuración en /etc tiende a ser caótica. Por citar algunos ejemplos...
    • Tengo lilo.conf, lilo.conf~, lilo.conf.nofunciona (si este es culpa mía); ¿pero si yo no uso lilo!! Yo uso grub...
    • Tambien tengo locale.gen, locale.gen~, locale.gen.dpkg-dist, locale.gen.user-es.bak, locale.gen.user-euro-es.bak. En este caso, ninguno es culpa mía.
    • El último ejemplo de este tipo XF86Config, XF86Config-4.custom, XF86Config.bak, XF86Config~, XF86Config-4.dpkg-old, XF86Config.user-es.bak, XF86Config-4, XF86Config-4.funciona, XF86Config.user-euro-es.bak y hoy cuando he cambiado el driver de «nvidia» a «nv» me he dado cuenta que el que funciona es xorg.conf.
  4. Y es que sobre /etc hay un problema adicional. Linux es un entorno tecnológicamente cambiante. Con el tiempo se van aportando soluciones distintas a los mismos problemas. Este giro de comportamientos hace que con algo de tiempo se junten todas estas «nuevas tecnologias obsoletas». Así tengo (en /etc/):

    oss, alsa, hotplug, usbmsg, modules-conf, lilo, grub, hal, discover, (ah, horror de los horrores:) netscape, mozilla, mozilla-firebird, mozilla-firefox, firefox, octave1.0.conf, octave2.0.conf........... (y sigue y sigue y sigue)

  5. En kernels modernos (digamos de los últimos 30 años ;-) existe una funcionalidad que es la autocarga de módulos. No se muy bien como funciona ni interesa en este momento; pero la historia es algo así a que si cargas el módulo B que requiere del A, este se carga en memoria sin pedirlo expresamente.

    El arranque de mi sistema es de lo más triste que he visto en mi vida. Es una sucesión de pantallas que dicen: «El módulo de sonido via-XX ya se cargó», «no hago nada porque el módulo de scsi ya está en memoria». Si ya sé, eso es fallo de una mala administración de mi parte. Y he visto que hay utilidades para analizar el arranque que en breve estudiaré.

  6. Igualmente tenía 10 imágenes de kernel. (alguna 2.2, varias 2.4 de la últimas versiones y dos o tres del 2.6). Con sus respectivos módulos.
  7. Cuando necesito programas que no están empaquetados, tengo que bajarme los fuentes y compilar. Esto me obliga a instalar librerias y librerias de desarrollo. (que luego no puedo borrar porque no me acuerdo para que las instalé).

Resumiendo. No se puede ir contra la termodinámica: los sistemas tienden a evolucionar a estados de mayor desorden.

Mi reflexion va sobre los ciclos de vida de estos sistemas. Un profesor de electrónica nos comentaba la tendencia de garantizar los componentes electrónicos de por vida. Como ahora hacen las memorias Kingstom. La trampa, decía, consiste en que la vida calculada a esa memoria superaba la vida de obsolescencia de la misma. Es decir el equipo que usa dicha memoria se quedará obsoleto ántes de la vida estimada del componente. Así que para uno que nos reclame dentro de 10 años, nos damos el pegote de la garantía de por vida.

¿Funciona la informática y el software de igual forma? Dicho de otra forma: mi servidor actual lo instalé hace un año con el software que necesitaba y solo hago actualizaciones de seguridad. Es estable. Mi equipo de trabajo instalo y desinstalo muchos programas y tengo la parte «administrativa» hecha una pena. ¿se supone que como los PC de trabajo se renuevan cada año o cada dos años se pueden permitir reunir basura?

¿Se ha diseñado linux para que sea estable a largo plazo, en ordenadores llamados «desktop»? o ¿tambien se requiere formatear el disco duro cada cierto tiempo y reinstalar desde cero para hacer limpieza?

< Nueva versión de Ubuntu 5.10 (3 comments) | 64 bits, ¿para quién? (36 comments) >
Enlaces Relacionados
· More on jamarier's Diary
· Also by jamarier

Encuesta
Y ahora...
· Con estudio, paciencia y horas de dedicación puedes sanear la administración del equipo 15%
· reformatea y reinstala. El tiempo de reconfigurar lo que tienes es muy inferior al tiempo de borrar lo que ya no usas. 7%
· Pues ninguno de estos problemas se favorecen en mi distro que es... (y lo pongo en un comentario) 0%
· Aguanta jamarier, aguanta (mi ordenador está como el tuyo y yo esperare a empezar mejor con el siguiente ordenador que me compre, y entonces poder formatear/reinstalar este como ordenador secundario) 15%
· Si es que tu eres el problema. Los ordenadores no son lavadoras. Son herramientas dificiles de usar. Si no sabes administrar para que te metes. (mi ordenador es 0% grasa sobrante) 7%
· Tu problema es de dinero. Contrata a un técnico que se encarge de la administración de tu equipo y tu dedicate solo a disfrutar de el (por cierto que tengo una empresa que hace eso y por....) 0%
· Oye ésta es casi tan larga como la de jorginius, que pase a portada para deleite de todos. 53%

Votos: 13
Resultados | Otras Encuestas

Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

Ver: Modo: Orden:
La estabilidad a largo plazo | 20 comentarios (20 temáticos, editoriales, 0 ocultos)
Distro sobre distro (none / 0) (#1)
por advocatux a las Mon Oct 31st, 2005 at 06:08:16 PM CET
(Información Usuario)

Efectivamente ocurren los efectos que comentas cuando tienes instalada una distro y la vas actualizando, problema que se agrava cuando:

* Un usuario, principalmente novato, prueba casi todo paquete que se le pone a tiro, instalando y desinstalando sin ton ni són. Digo lo de novato porque ni siquiera toma precauciones y/o desconoce los efectos de lo que está haciendo (se supone que un usuario avanzado controla mejor esto, pero tal vez sea mucho suponer).

* Un usuario lo que prueba no son paquetes sino distros completas, manteniendo algunas particiones (por ejemplo /home, /etc y demás) y ya sabemos que cada distro le da por instalar sus cosas en donde mejor le parece.

Conclusión: si se desea tener una máquina con una cierta limpieza (sobretodo "estación de trabajo" ya que, normalmente, hay menos juegos de esta clase en servidores), la solución más simple y asequible a todos los niveles pasa por hacer copia de seguridad e instalar desde cero.
--
- Por una Europa libre de Patentes de Software - EuropeSwPatentFree


 
Ni comparable ni tan problemático (none / 0) (#2)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Mon Oct 31st, 2005 at 08:44:24 PM CET
(Información Usuario) http://speedball.servemp3.com

La mayoría de las veces el tener ficheros de configuración inútiles no afecta excesivamente a nuestro sistema. El tener cientos de ficheros /etc/lilo.conf* en nada afecta exceptuando en el espacio de disco consumido (4KB por fichero, aproximadamente) y la posible fragmentación que pueda aparecer si el disco esta muy ocupado. Esto es así porque absolutamente todos los programas del sistema están ignorando dichos ficheros. El único que hará algo de caso a uno de esos ficheros será precisamente el /sbin/lilo.

Además, el sistema de ficheros en el que se encuentra /etc acostumbra a ser poco volátil, no suele haber excesivo movimiento de ficheros (comparado con el /home). Normalmente la gente dedíca más tiempo a usar los programas que a instalar o desinstalar programas.

Con un poco de cuidado y orden, se puede hacer limpieza del directorio /etc, aunque la mejora no será precisamente grande. Es más ventajoso en cuestión de rendimiento el minimizar la cantidad de servicios del sistema, y pasar el máximo posible al xinetd/inetd ¿para qué tener el sshd como daemon en una máquina que tendrá muy pocas conexiones entrantes por ssh, y apenas nunca varias a la vez?.

Dónde siempre he encontrado un problema ha sido en los $HOME. Ahí si que siempre ha sido un caos. Un caos que además es incoherente con el resto del sistema.

Mientas que en el sistema es normal tener las configuaciones en /etc, /usr/etc y /usr/local/etc según ciertos criterios, que deberían ser según dónde se instale cada aplicación o subsistema, pero queda más bien a criterio de la distribución o incluso del desarrollador, lo lógico sería que las configuraciones del usuario local, en lugar de estar en la raíz del $HOME como ficheros ocultos, estuviesen dentro de un directorio $HOME/etc o incluso si me apuran $HOME/.etc. Ahí además debería ordenarse un poco más, pero ya el que una vez dentro del directorio los ficheros no sean ocultos ya sería mucho más cómodo.

Supongo que la razón que esto no fuese así en un principio se debe a que era muy habitual hacer que los usuarios no pudiesen moverse del $HOME, y ni tan siquiera podían crear directorios en su própio directorio. Como esto ya no esta de moda entre los administradores, y menos si los usuarios tienen provilegios para crear sesiones gráficas, los modernos entornos de escritorio ya tienen un directorio centralizado para las configuraciones de las aplicaciones.

De todas formas, esto añadiría limpieza y comodidad para el usuario y el administrador, pero no solucionaría el problema de los cientos de ficheros de configuración de aplicaciones que quizás ya no estén, o de versiones diferentes: imaginemos que por alguna razón se realiza una desactualización, o se comparte el $HOME entre sistemas que tienen versiones muy diferentes del mismo programa, podría ser que una aplicación no entendiese su propio fichero de configuración.

No hay una solución fácil para mantener los home directory con poca basura, basura que puede llegar a ocupar bastante en según que situaciones. No se me ocurre ninguna forma que sea eficiente, segura y automatizada para eliminar de los $HOME aquellos ficheros de configuración que sean obsoletos.

Speedball la banda de heavy más chunga
Ven al Helvete Metal Bar


Paciencia y haz paquetes (none / 0) (#3)
por jorginius ("jorginius" en Google Mail) a las Mon Oct 31st, 2005 at 09:57:59 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Cuando necesito programas que no están empaquetados, tengo que bajarme los fuentes y compilar. Esto me obliga a instalar librerias y librerias de desarrollo. (que luego no puedo borrar porque no me acuerdo para que las instalé).

Para evitarlo yo procuro hacer mis propios paquetes.

Hacer un rpm a partir de un tarball que use autoconf+automake me lleva 2 minutos escasos. No son los mejores rpm del mundo, no tienen opciones, ni changelog, ni la descripción en diez idiomas, ni unos scripts espectaculares de post instalación y tampoco son reubicables pero para evitarme el problema me basta con que tengan bien puesta la categoría y lleven marcadas las dependencias.

La categoría la debo colocar yo a mano ("User Interface/X", "System Environment/Libraries", etc.) y para el cálculo de las dependencias ya tengo rpmbuild/find-requires que lo hace por mí.

Aparte de eso suelo poner una release particular en el nombre ("1mio", "2mio", etc.) para distinguir mis paquetes caseros en la base de datos.

En tu caso, que ya tienes el lío montado con un montón de cosas instaladas, yo haría lo siguiente:
  1. Escribir un script que repase todo lo que haya en un "/usr/local" (y/o "/usr" si cometí el error de instalar software ahí a mano) y compruebe si pertenece a algún paquete (rpm -qf). En caso contrario añado su ruta a una lista.
  2. Escribir ahora un spec dando de entrada el listado en el campo "files".
  3. Construir ese "meta-paquete". Con todas las dependencias que requiere (y las que ofrece, si incluyo bibliotecas) calculadas por rpmbuild.
  4. Para finalizar lo instalo y ya tengo controladas todas las dependencias de lo que en su día instalé a las bravas.


Lo mala noticia es que esto que es tan fácil de hacer con rpm es un incordio hacerlo con deb. AFAIK en Debian es tarea del empaquetador estimar las dependencias. No hay una herramienta que, dado unos binarios, las calcule por ti (o yo no la conozco).

¿Se ha diseñado linux para que sea estable a largo plazo, en ordenadores llamados «desktop»? o ¿tambien se requiere formatear el disco duro cada cierto tiempo y reinstalar desde cero para hacer limpieza?

Bueno, estable sigue siéndolo a pesar de la basurilla.

¿Linux en el "desktop"?. Depende, por mucho que se intente facilitar el trabajo, mantener un Linux exige disciplina y saber dónde va cada cosa. Necesita dedicarle tiempo que a veces no se tiene y esto choca con la idea de un ordenador "desktop" entendiendo éste como chisme que enciendes, trabajas con él y exige mantenimiento mínimo o nulo (como la lavadora).

Siguiendo FHS, estándar POSIX y demás opino que Linux no podrá ser nunca un sistema operativo para ordenadores "desktop", igual que un tanque no será nunca un coche familiar por mucho que le pongamos aire acondicionado y lo pintemos de rojo burdeos.

Y no es por falta de esfuerzos, cada distro se está dejando las pestañas buscando formas de esconder toda esa complejidad con herramientas automáticas pero... Lo que consiguen al final es añadir más y más complejidad: "meta-ficheros" de configuración que se usan para generar otros ficheros de configuración que a su vez..., scripts de arranque que se llaman unos a otros y son imposibles de seguir, asistentes de asistentes (aptitude sobre apt o synaptic), etc, etc.

Creo que se está perdiendo el Norte. Quiero decir, a nadie le amarga tener apt, yum o portage (sobre todo conociendo la alternativa) pero me parece que se están perdiendo intentando llevarlo más allá. No se puede hacer algo sencillo (realmente sencillo, y no hablo de Windows o de Mac OS sino de lo que debería ser un sistema "desktop" real) y a la vez tratar de mantener el "aspecto Unix", con toda su potencia y complejidad, porque al final obtienes algo que no hay quien le meta mano (ni el novato ni el admin) y que no contenta a nadie.

Como respuesta a toda esto han estado saliendo de un tiempo a esta parte distros sencillas. Archlinux, o CRUX son distribuciones en las que los scripts de arranque son simples, los archivos de configuración son reconocibles y, lo más importante, no empiezan con un "CUIDADO: no edite este archivo ya que ha sido generado automágicamente por menganitux a partir del perfil que guarda fulanitux".

Igual que hay distribuciones que apuestan decididamente por la simplicidad para el admin, debería haberlas que apostaran decididamente por la simplicidad para el usuario. Convertir el ordenador en una especie de PDA gigante o un kiosko en el que no haya que mantener nada ni configurar nada ni pensar en los detalles.

En Linux eso se puede hacer, de hecho es más fácil en Linux que en otros sistemas porque aquí puedes meterle mano a todos los componentes y reescribir lo que haga falta para conseguirlo. Por contra lo que se está haciendo es intentar bastardizar un Unix buscando una supuesta sencillez, y no parece que la encuentren.



 
Combatir el caos (none / 0) (#4)
por atopos a las Mon Oct 31st, 2005 at 10:01:46 PM CET
(Información Usuario) http://los-pajaros-de-hogano.blogspot.com

Conozco bien a lo que te refieres. Es un problema que a mí también me incomoda (y alguna vez, incluso, hasta me atormenta). Problamemente se trate de una cuestión meramente estética. Como han dicho por ahí, el efecto real sobre el rendimiento es seguramente mínimo, pero no puedo renunciar a querer ver mi sistema tan limpio y ordenado como quedó tras la primera instalación.

aptitude pone algo de orden en el tema, como has dicho. Una cosa que me gusta, por ejemplo, es que sus acciones quedan claramente registradas en /var/log/aptitude.

Otra cosa son los ficheros de $HOME... Mi semi-solución provisional es más o menos la siguiente:
  • Llevar nota en un cuaderno de todo lo que instalo y modifico.
  • Etiquetar convenientemente todos los ficheros de configuración que transformo. Así siempre tengo a mi disposición las versiones originales y mis modificaciones.
  • Tomar nota de qué ficheros/directorios ocultos se crean en $HOME cada vez que ejecuto un programa recién instalado.
En realidad el último paso no lo realizo exhaustivamente. Es decir, empiezo a hacerlo, pero pierdo la paciencia y no llevo siempre la cuenta, como quisiera. Siempre ando pensando en crear un guión que automatice la tarea (quizá hasta ya exista y no lo sepamos), pero la pereza, en mi caso, ha vencido hasta el momento. Estaría encantado de que alguien más escrupuloso o con menor desidia lo hiciera por mí. Tú mismo, por ejemplo ;)



La estabilidad a largo plazo | 20 comentarios (20 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda