Libertonia || Comments || Configuraciones gráficas


Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios

Configuraciones gráficas | 27 comentarios (27 temáticos, editoriales, 0 ocultos)

registry (none / 0) (#6)
por FidoX a las Wed Aug 18th, 2004 at 08:19:08 PM CET
(Información Usuario) http://www.corebedigital.com

El usar XML para los ficheros de claves está totalmente descartado de momento. No tiene ninguna razón de ser, ya que en cada fichero solo se graban algunos datos, los cuales deben ser fácilmente editables con el vi. Además, tampoco me imagino teniendo que meter todo el código de parseo de XML en la glib, por ejemplo o tenerlo que portar a todas las plataformas en las que ejecute apache.

Sobre el tema de un fichero por clave... pues bueno, han corrido ríos de tinta (o de bytes) sobre ese tema. La conclusión a la que hemos llegado es que no es un problema del que debamos preocuparnos. Primero, porque se puede cambiar sin mayor problema en cualquier momento y todas las aplicaciones seguirían funcionando exáctamente igual.

En segundo lugar porque hay sistemas de archivos que están muy optimizados para ficheros pequeños. Si no quieres usar ese sistema de archivos, puedes crearte una partición virtual con el loop. (en linux, al menos)

Así, tienes la ventaja de poder fijar permisos, por ejemplo para que un usuario pueda modificar la configuración de un servidor virtual de apache, pero no la configuración genérica y cosas así.

De todas formas, ya digo que éste no es el momento de preocuparnos por esas cosas, porque incluso podrían subsistir claves en grupo y claves por ficheros en el mismo sistema.

Además algo que me gusta a mi particularmente, es la posibilidad de indicarle a alguien un cambio en la configuración ejecutando un simple comando:

bash$ rg set /system/hw/net/address "192.168.1.1"

mediante ese comando se podría cambiar la IP de la máquina. Además con el sistema de notificaciones se podría resetear la interfaz para que el cambio sea inmediato.

Otra posibilidad es la de tener pequeños scripts que te permitan a base de preguntas configurar los parámetros básicos de varios ordenadores a la vez.

Si todos los valores van a ser los mismos, supongo que ahora se podriá hacer sobreescribiendo los ficheros a lo béstia. Pero de ésta forma, cualquiera podría hacerse un script en bash a base de read y rg que con preguntas sencillitas configure la red, las X, los puntos de montaje, /etc/hosts, /etc/resolv.conf, etc...

Ya ven que las ventajas no están solo en las interfaces gráficas, que a mi personalmente por llevar mucho tiempo usando una shell bash, tampoco me agradan mucho. Yo he podido encontrar ventajas que me venefician a mi personalmente que no tengo ningún problema en editar cualquier fichero con vi. El hecho es que éste sistema es más o menos parecido, pero con un poco de ayuda para hacerlo más... moderno ;)

Creo que las ventajas son muchas y al fin y al cabo solo estamos modificando los ficheros de configuración que no va a suponer ningún cambio drástico en la manera de funcionar de los programas. Seguirán funcionando igual de estables (o inestables ;)) a la misma velocidad y exactamente de la misma forma, solo que, creo yo, acabarán teniendo conocimiento de sus programas vecinos y serán más cómodos de configurar.
Israel E. Bethencourt
FidoX/CORE

Sí y no... (none / 0) (#8)
por raster a las Sat Aug 21st, 2004 at 02:45:44 AM CET
(Información Usuario)

Hombre, el problema de los inodos creo que se puede considerar bastante serio. Fijate que dices que se puede crear un sistema de archivos en un fichero y montarlo por loop. ¿Y si casca el archivo que contiene dicho sistema de ficheros? Sería tener el registro en un único fichero, como en windows, con todos sus problemas.

Sí es cierto que el API permite abstraerse por completo de si se guardan las claves en ficheros independientes o no, salvo en un único detalle: se pueden especificar privilegios a cada entrada de manera independiente. Eso ya obliga a que las entradas estén cada una en un fichero (no sirve de nada incluir los permisos junto a cada clave porque se tiene que poder acceder al fichero global, con lo que, aunque las herramientas no lo permitan, sólo tendría que ir con vi y tira millas). Si hicieseis que los permisos se aplicasen a todas las entradas de un nivel, permitiríais ambos casos y sin pérdida de generalidad (se meten en un nivel las que sólo puede cambiar una persona, en otro las que puedan cambiar todo el mundo, etc, y se asignan los permisos en concordancia por grupos).

Puedo parecer pesado, pero creo que es un tema muy importante: de él puede depender que sea aceptado o no. Yo, desde luego, pondría muchos reparos a un registro con un fichero por entrada (aunque repito que la idea del registro en sí me parece magnífica). Si sólo cambiaseis ese detalle en el API, sería perfecto (afecta a las llamadas KeyGetUID, KeySetUID, KeyGetGID, KeySetGID, KeyGetAccess y KeySetAccess), aunque no lo implementeis de momento. Al menos no cerraríais la puerta a la posibilidad de "varias claves=un fichero".

[ Padre ]

Permisos (none / 0) (#9)
por man ls a las Mon Aug 23rd, 2004 at 12:18:08 AM CET
(Información Usuario)

No creo que los permisos sean un obstáculo; si se meten varias claves en un fichero, se pueden añadir los permisos en él o incluso en otro fichero del mismo directorio.

Sí creo que lo importante es que se adopte un sistema global de configuración, y los detalles de implementación se irán puliendo luego -- es imposible hacerlo todo correcto a la primera. Cuando sea posible configurar un sistema con scripts, en red, de forma gráfica y desde línea de comandos (sin artefactos extraños como el sistema de ficheros /proc) la vida de los BOFHs mejorará bastante; si además es seguro, fiable, grepable y sin problemas de sincronización, tendremos un sistema operativo sin rival.

[ Padre ]

registro = /etc (none / 0) (#10)
por musg0 a las Mon Aug 23rd, 2004 at 09:34:59 AM CET
(Información Usuario) http://helvete.escomposlinux.org

Cuando sea posible configurar un sistema con scripts, en red, de forma gráfica y desde línea de comandos (sin artefactos extraños como el sistema de ficheros /proc) la vida de los BOFHs mejorará bastante; si además es seguro, fiable, grepable y sin problemas de sincronización, tendremos un sistema operativo sin rival.

Yo creo que el registro ya lo tenemos y se llama /etc.

Lo que sí debería hacerse ya es organizarlo porque /etc se está desmadrando un poco.

Estaría bien tener todas las configuraciones de los programas colgando de /etc/programs/nombre-version-subversion/

Así cada programa podría hacer lo que le viniera en gana pero no tendrías que pensar nada para saber donde está su configuración.

En Debian por política todas las configuraciones de los programas tienen que ir a /etc. Estaría bien que se llegara un paso más allá y se se organizara por versiones. Así, al instalar los paquetes te podría preguntar si quieres borrar la última configuración, moverla, copiarla, instalar la que viene en el paquete, etc...

Estaría todo ordenado en una jerarquía como en /usr/share/doc y dentro de cada directorio de programa ya sería labor del programa el cómo leer sus configuraciones ya que no creo que se necesite una forma común de trabajar con ellas.

[ Padre ]

Tiene sus limitaciones (none / 0) (#11)
por man ls a las Mon Aug 23rd, 2004 at 10:14:15 AM CET
(Información Usuario)

Guardar todas las configuraciones de /etc no es la panacea. Varios ejemplos de cosas que no están resueltas:

Configuraciones de usuario. Ahora mismo, los programas derraman sus configuraciones por todo mi $HOME, cuando yo preferiría que todas estuvieran en $HOME/.etc o algo parecido.
Configuraciones para X. Si arranco una sesión X remota, ¿qué valores debería usar, los míos locales o los del servidor?
Siguiendo con lo mismo, algunos programas usan Xresources y otros ficheros locales.
No es fácil centralizar todas las configuraciones para varias máquinas en un servidor.
No se guardan las versiones antiguas de los ficheros de configuración, para poder deshacer los cambios.
Hay que reiniciar los programas o decirles que vuelvan a leer la configuración después de cada cambio.

Una forma común de leer configuraciones podría resolver estas cuestiones de un plumazo.

[ Padre ]

Yo no las veo (none / 0) (#12)
por musg0 a las Mon Aug 23rd, 2004 at 12:03:51 PM CET
(Información Usuario) http://helvete.escomposlinux.org

# Configuraciones de usuario. Ahora mismo, los programas derraman sus configuraciones por todo mi $HOME, cuando yo preferiría que todas estuvieran en $HOME/.etc o algo parecido.

Al igual que en mi ejemplo hay un /etc/programas/nombre-version podría haber lo mismo en cada directorio de usuario. En Debian se modifican muchas fuentes para que usen /etc. Podrían también cambiar esos programas para que usen ~/.etc/programs/nombre-version/ para guardar las configuraciones locales. Esto no necesita nueva infraestructura si no una recompilación con los cambios pertinentes a las rutas.

# Configuraciones para X. Si arranco una sesión X remota, ¿qué valores debería usar, los míos locales o los del servidor?

Yo creo que la configuración del ordenador que está ejecutando ese programa. El programa puede estar instalado en un servidor remoto pero se está ejecutando en la máquina local. Por ahora no creo que haya nada que haga streaming de configuraciones por red.

# Siguiendo con lo mismo, algunos programas usan Xresources y otros ficheros locales.

Estos serían configuraciones del DISPLAY, ¿no?. Me parece lógico ya que el DISPLAY es local a la máquina en la que estás y no se está "ejecutando" en otra máquina. No veo problemas en esto. Repito que lo raro me parecería tener que hacer una especie de streaming de las configuraciones por red. Me parece que no me queda claro lo que quiero comunicar...

# No es fácil centralizar todas las configuraciones para varias máquinas en un servidor.

Con los HOME exportados por NFS nunca ha habido problemas de eso. Tienes un sólo directorio de usuario para todas las máquinas. El problema vendría si las máquinas son heterogéneas y no se usa la misma versión del software en todas, pero para eso exportar /usr por NFS también es la solución.

# No se guardan las versiones antiguas de los ficheros de configuración, para poder deshacer los cambios.

Con lo que digo del /etc/programs se arreglaría ya que las configuraciones serían por paquete. En mi opinión parte de la solución la tienen los desarrolladores de la distribución que deberían hacer herramientas para controlar las versiones de las configuraciones y al crear el paquete tener en cuenta eso. En Debian creo que no habría mucho problema en ampliar la política de forma que todas las configuraciones estén más jerarquizadas.

# Hay que reiniciar los programas o decirles que vuelvan a leer la configuración después de cada cambio.

De toda la vida un kill -HUP ha servido para que relean las configuraciones. Parece que se ha perdido esa sana costumbre y no veo porqué es necesaria una infraestructura nueva. Con lo poco que tiene Unix se pueden hacer bien las cosas sin inventar nada nuevo.

[ Padre ]

Todo es posible (none / 0) (#13)
por man ls a las Mon Aug 23rd, 2004 at 12:35:36 PM CET
(Información Usuario)

No, si todo se puede hacer. El problema es que no se hace. Ni se recompilan los programas para que dejen las configuraciones de usuario en un sitio decente, ni se organiza /etc, ni se hacen herramientas para gestionarlo, ni se usan los Xresources (esto que lo explique otro que tenga más experiencia, yo conozco el problema de oídas). Y a lo mejor no se hace porque es demasiado trabajo -- mientras que una infraestructura nueva lo haría más sencillo.

Hay un punto que no he explicado bien:

# No es fácil centralizar todas las configuraciones para varias máquinas en un servidor.

Me refería no a las configuraciones de usuario, sino a las del sistema. Vamos, como si exportáramos /etc por NFS. Hay soluciones parciales como DHCP, que permite asignar direcciones IP dinámicas, pero nada que funcione de forma global.

¿Para qué serviría semejante engendro? Por ejemplo para tener un cluster de servidores web. Me dirás que en este caso se puede exportar /etc por NFS, pero como decía Manzano en La Estanquera de Vallecas, "ej que no é lo mimmo". Tienes que embarcarte en una tarea laboriosa de poner configuraciones por defecto en local, montar el directorio, luego leer las configuraciones remotas y que coincidan; cualquier cambio en la configuración por defecto y tienes que cambiar todas las máquinas.

[ Padre ]

¿Para qué quieres configuraciones locales? (none / 0) (#16)
por jorginius ("jorginius" en Google Mail) a las Mon Aug 23rd, 2004 at 08:25:09 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Por ejemplo para tener un cluster de servidores web. Me dirás que en este caso se puede exportar /etc por NFS, pero [...] Tienes que embarcarte en una tarea laboriosa de poner configuraciones por defecto en local, montar el directorio, luego leer las configuraciones remotas y que coincidan;

¿Por?, ¿para qué necesitas las configuraciones locales en ese caso? y ya puestos, ¿para que necesitas que los nodos tengan discos?.

Otras opciones son rsync de la configuración del nodo maestro, usar LDAP o NIS para centralizar cuentas y grupos, etc. Pero la más evidente es exportar /etc. Lo que planteas me parece que tiene vieja solución.

[ Padre ]

Para montar las unidades (none / 0) (#19)
por man ls a las Mon Aug 23rd, 2004 at 11:32:45 PM CET
(Información Usuario)

¿Por?, ¿para qué necesitas las configuraciones locales en ese caso? y ya puestos, ¿para que necesitas que los nodos tengan discos?.

El objeto es, por supuesto, tener las mismas configuraciones de apache.

Me baso en mi grandísima ignorancia: tendrás que tener la configuración para que el equipo medio-arranque, y luego un fstab para montar las unidades remotas, ¿no? Parece mucho mejor desde luego no tener ni discos, pero eso ya es demasiado sofisticado para mí.

[ Padre ]

No, en realidad no (none / 0) (#21)
por jorginius ("jorginius" en Google Mail) a las Tue Aug 24th, 2004 at 11:39:51 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

tendrás que tener la configuración para que el equipo medio-arranque, y luego un fstab para montar las unidades remotas, ¿no?

El raíz se monta antes que se lean los guiones de arranque (y las configuraciones) y éste lo puedes montar por NFS. En el raíz puedes colocar el /etc/ junto a los puntos de montaje (que se montaran en remoto o en local: al gusto) o puedes colocar todo el sistema de archivos y no usar sistemas de archivos locales para nada.

En realidad lo único que no pueden compartir los nodos es el /tmp, el /var, el /dev y la swap, pero lo del /dev lo puedes manejar con devfs o, imagino, udev, el /tmp y el /var meterlos en un mini-disco ram incluido en el kernel y la swap desactivarla. También haría falta un syslog-ng para centralizar todos los logs de los nodos en un mismo punto.

Para arrancar, te puedes hacer un floppy de arranque con un kernel en plan tú mismo o usar Etherboot. O ya puestos a prescindir de partes móviles, puedes grabar Etherboot en la prom de la tarjeta de red.

En el Diskless-root-NFS HOWTO tienes descrito cómo se haría. Admite mejoras pero básicamente es eso.

[ Padre ]

¿Y no se hace así ya? (none / 0) (#17)
por jorginius ("jorginius" en Google Mail) a las Mon Aug 23rd, 2004 at 08:36:41 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Al igual que en mi ejemplo hay un /etc/programas/nombre-version podría haber lo mismo en cada directorio de usuario.

La mayoría de los programas tienen una configuración global en /etc, que luego el usuario puede reescribir en su home mediante el pertinente ".archivo" (KDE y Gnome incluidos). El resto de los programas que no se adscriben a eso es porque no tiene sentido que cada usuario tenga una configuración de los mismos (cada usuario con una configuración diferente de Sendmail, por ejemplo).

[ Padre ]

Eso es así (none / 0) (#25)
por musg0 a las Fri Aug 27th, 2004 at 12:49:41 PM CET
(Información Usuario) http://helvete.escomposlinux.org

Pero lo que yo digo es que haya un estándar para que todas las configuraciones de los programas de /etc estén ordenados.

Lo mismo dentro de cada directorio de usuario.

Debian tiene por política meter todas las configuraciones dentro de /etc. Podrían ir más lejos y exigir que cada programa ponga sus configuraciones dentro de su directorio, al igual que se hace con /usr/share/doc.

Al final, si /etc está ordenado es un registro de esos milagrosos que parece todo el mundo está intentando reinventar.

[ Padre ]

Ok, pero no veo grandes ventajas (none / 0) (#27)
por jorginius ("jorginius" en Google Mail) a las Fri Aug 27th, 2004 at 02:01:08 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Pero lo que yo digo es que haya un estándar para que todas las configuraciones de los programas de /etc estén ordenados. Lo mismo dentro de cada directorio de usuario.

Sí, es verdad que dijiste eso. Lo lei por encima y respondí a lo que quise. Perdón :-D

Debian tiene por política meter todas las configuraciones dentro de /etc. Podrían ir más lejos y exigir que cada programa ponga sus configuraciones dentro de su directorio

Bueno, de todas formas, de $HOME puedes asumir que existe y que puedes escribir en él. Para otro directorio que pendiese de $HOME habría que comprobar por aplicación si existe o no y cuáles son los permisos antes de escribir la configuración. Tampoco es que sea mucho más pesado (eso mismo se hace en KDE con ~/.kde/) pero sí es una pequeña molestia. Por otro lado muchas aplicaciones, la mayoría, te permiten indicar dónde buscar el archivo de preferencias, ya sea por línea de órdenes o por una variable de entorno, así que puedes ordenarlo tú mismo desde ya.

Personalmente no veo diferencia entre tener un/os subdirectorio/s dentro de $HOME para la configuración y tenerla en el raíz de él. Yo no tengo en el $HOME más que algunos subdirectorios propios (lo típico: "proyectos", "cajón", "música", "correo", etc.) y los archivos y subdirectorios con la con las configuraciones (".*"), y tanto me da hacer "vi ~/.bashrc" que "vi ~/etc/bashrc" o "vi ~/etc/bash/rc".

Si lo que no le gusta a la gente es tener mezclados en el raíz de $HOME los archivos propios con los archivos ocultos de configuración, que procure mantener los suyos separados en un directorio "trabajos" o similar... Y si lo que molesta es tener que andar haciendo cd tras el login, el usuario siempre puede, por ejemplo, escribir un archivo tal que:

# .chgcd $Id$
cd ~/trabajos

Añadir al final del ~/.bashrc:

source ~/.chgcd

Y ya no pisar el raíz de $HOME para nada.

Imagino que no descubro nada nuevo pero plantar un "cd ~/trabajos" tal cual al final del .bashrc no funcionaría por razones obvias. Esto no es DOS :-D.

[ Padre ]

Eso es así (none / 0) (#26)
por musg0 a las Fri Aug 27th, 2004 at 12:55:45 PM CET
(Información Usuario) http://helvete.escomposlinux.org

Pero lo que yo digo es que haya un estándar para que todas las configuraciones de los programas de /etc estén ordenados. Lo mismo dentro de cada directorio de usuario.

Debian tiene por política meter todas las configuraciones dentro de /etc. Podrían ir más lejos y exigir que cada programa ponga sus configuraciones dentro de su directorio, al igual que se hace con /usr/share/doc.

Muchos programas en Debian se modifican para que su configuración caiga en /etc. Como digo ya puestos podrían organizar un poco /etc y que cada programa tenga sus configuraciones ordenadas por nombre y versión.

Al final, si /etc está ordenado es un registro de esos milagrosos que parece todo el mundo está intentando reinventar.

[ Padre ]

Los Xresources y RCS, ese gran desconocido (none / 0) (#18)
por jorginius ("jorginius" en Google Mail) a las Mon Aug 23rd, 2004 at 08:52:38 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Configuraciones para X. Si arranco una sesión X remota, ¿qué valores debería usar, los míos locales o los del servidor?

Evidentemente si el servidor X va a correr en tu máquina, sobre tu hardware, la configuración del servidor debe ser la local. De las aplicaciones que escriban en tu display dependerá de desde dónde corran.

Siguiendo con lo mismo, algunos programas usan Xresources y otros ficheros locales.

Eso cada vez es menos problema porque ya hay pocas aplicaciones que usen sólo Xresources: o te dan la opción de configurarlas de las dos formas o usan sus propios archivos de configuración. Ahora mismo sólo se me ocurre xedit y familia como ejemplos de aplicaciónes "sólo Xresources".

No se guardan las versiones antiguas de los ficheros de configuración, para poder deshacer los cambios.

No las guardarás tú :-D. Yo uso RCS para mantener el control de versiones de lo que hay en mi /etc. Tengo en todo momento el histórico de los cambios que he ido haciendo, puedo generar los parches, deshacer, rehacer, etc.

Sobre lo de compartir la configuración (exportar /etc) e indicarle a los programas que lean de nuevo los cambios (kill -HUP) ya te ha dicho musg0 un poco más abajo todo lo que yo podría decir :-).

[ Padre ]

Qué virguero (none / 0) (#20)
por man ls a las Mon Aug 23rd, 2004 at 11:33:15 PM CET
(Información Usuario)

Yo uso RCS para mantener el control de versiones de lo que hay en mi /etc.

Qué buena idea, me gustaría saber cómo hacerlo -- ¿hay algún HOWTO por ahí?

De todas formas, el problema sigue siendo el mismo: tienes que currártelo tú y hacer todo el montaje. Con un sistema uniforme de configuración se podría hacer automáticamente, de forma que sea fácil hasta para novatos como yo.

[ Padre ]

Pregunta a Google (none / 0) (#22)
por jorginius ("jorginius" en Google Mail) a las Tue Aug 24th, 2004 at 01:24:26 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

La verdad es que ya no me acuerdo de a quién se lo vi hacer primero pero no es que sea una idea novedosa ni rara. He consultado en Google y en Slashdot se preguntan "Linux Distros with CVS/RCS for Config Files?". Ahí se vé como la gente usa también CVS o Subversion para controlar la configuración. También hay un tip publicado en la Linux Gazette de Noviembre de 1995: RCS: Managing System Config Files.

No es que mi método sea muy complicado. Sólo uso RCS, un editor que lo soporte (por comodidad, por no andar actualizando los cambios a mano cada vez que toco algo) y un poco de Bash scripting y cron para hacer revisiones de seguridad si algo cambió y no fuimos mi editor y yo los que lo cambiamos.

Editores con soporte de RCS hay muchos pero si el tuyo no tiene puedes adaptarle algo como esto, sacado del mismo hilo de Slashdot, RCS and vim. Dice "Vim" pero parece que Vim sí tiene soporte RCS, aunque el script de /. tiene algunos pluses interesantes (más transparente, lista de que no hay que mantener bajo control, etc).

De todas formas, el problema sigue siendo el mismo: tienes que currártelo tú y hacer todo el montaje.

Bueno, en Gentoo tienen algo similar de serie, llamado dispatch-conf y tampoco es que me parezca un problema el que tenga que currármelo yo para mi problema concreto:

Esto es Unix y la filosofía de Unix es "cómo es imposible adaptarse a todo, damos las herramientas y que cada cual se construya su solución a la medida". Hay quien adora esto y otros que no. En Windows o en Mac la idea es que hay una solución adecuada para el 90% de la gente y el resto o se joden o lo tienen más crudo para montarse la suya propia. Es cuestión de ver en que porcentaje caes.

Vamos, que a mí me parece chachi que se haga un sistema de configuración como los que proponéis, siempre que no me obliguen a usarlo y lo pueda dejar todo como estaba sin traumas :-D.

[ Padre ]

Otra aproximación interesante (none / 0) (#24)
por jorginius ("jorginius" en Google Mail) a las Tue Aug 24th, 2004 at 05:34:58 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

... Es integrar el control de versiones en un sistema de archivos, y usarlo para el /etc.

El ClearCase FS (ClearCase de Rational/IBM) contabiliza de forma transparente las modificaciones que hagamos en los archivos que contiene. Si queremos consultar una versión previa, lo único que tenemos que hacer es leer "archivo@@/versión" como si leyésemos un archivo más (esos "*@@/versión" no aparecen en el listado regular de archivos y directorios). Se cambien como se cambien los archivos en ese sistema, la coherencia en los históricos no se pierde... Y para el que no quiere enredar es ideal puesto que más cómodo y simple imposible: el sistema de archivos lleva el control de versiones por ti.

Algo así es interesante precisamente para la partición con las configuraciones o para la partición donde guardemos nuestro trabajo :). Clonar el ClearCase FS (que hay para varias plataformas, includa Linux) puede ser un buen proyecto.

[ Padre ]

registry (none / 0) (#14)
por FidoX a las Mon Aug 23rd, 2004 at 01:21:06 PM CET
(Información Usuario) http://www.corebedigital.com

Yo creo que el registro ya lo tenemos y se llama /etc.

Hombre, pues sí. Nuestra idea es no alejarnos demasiado de /etc. Pero también queremos aportar algo, no nos basta con reorganizar el directorio.

Yo he tenido que trastear un poco con los ficheros de configuración de la glibc y aunque desde fuera no se vea, se hacen cosas un poco feas con los ficheros de configuración. No hay un API medianamente estandarizada dentro del a propia glib. Y bueno, a mi me gustaría que hubiese un api que los programadores pudiesen usar para implementar sus sistemas de configuración porque no tengas que dedicarle mucho tiempo, al fin y al cabo, solo es la configuración. No tengas que reescribir las mismas instrucciones una y otra vez, de leer y escribir en fichero, controlando los errores de sintaxis, falta de claves, etc. Algo que usen porque les resuelve la vida en ese sentido y además después queda integrado con todo el sistema.

Hay varios proyectos en ese sentido, pero nosotros pretendemos ir un poco más allá intentando buscar una organización un poco más óptima.

A mi /etc me parece bien, pero si buscaramos algo que poder hacer para mejorarlo un poco, creo que sería ésto.

Estaría bien tener todas las configuraciones de los programas colgando de /etc/programs/nombre-version-subversion/

Es más o menos nuestra idea, pero ya que vas a intentar hacer algo así, pues creas un api más o menos consistente para que los programadores la puedan usar, y optimizas un poco los ficheros para que sea más fácil de tratar.

Sobre el tema de los detalles técnicos, pues de momento estamos en una fase muy temprana y aún hay cosas que tenemos que descubrir. Pero no hemos cerrado ninguna puerta.

Israel E. Bethencourt
FidoX/CORE
[ Padre ]

registry (none / 0) (#15)
por FidoX a las Mon Aug 23rd, 2004 at 01:35:59 PM CET
(Información Usuario) http://www.corebedigital.com

¿Y si casca el archivo que contiene dicho sistema de ficheros? Sería tener el registro en un único fichero, como en windows, con todos sus problemas.

Bueno... Si casca el disco duro vas a tener problemas independientemente de cómo tengas organizada la información. Y un fichero de loop es bastante fácil de recuperar.

Sobre los problemas que comentas sobre el registro de windows. Realmente el problema no está en que sea un solo fichero, sino en que solo hay un método de acceso. Si metieramos el registro en un fichero binario donde solo nuestra api pudiera acceder, tendríamos un problema parecido al de windows (aunque nunca de tal magnitud, claro está). Que es, básicamente el obscurecimiento de su funcionamiento. En nuestro caso nunca llegaremos a ese punto, porque nuestra meta principal es que esté todo bien a la vista.

Un buen ejemplo, podría ser la recuperación de una clave de administrador.

La semana pasada tuve que recuperar la clave de administrador de un WinXP. Eso en linux es bastante fácil. Arrancas con un disco de rescate y modificas el fichero /etc/passwd. Si el registro estuviese implementado, el proceso sería exactamente el mismo, puedes recuperar la clave con las herramientas mínimas.

En el caso de WinXP recuperar la clave es un poco más complicado. ¿Porqué? Realmente no porque esté toda la configuración en un solo fichero. El problema es que para acceder a ese fichero son necesarios una serie de recursos de los que no se pueden disponer fácilmente. Hay que hacer un poco de ingeniería inversa para modificar el registro con cuidado de no romper nada, para una tarea tan simple como modificar la clave.

Eso en un sistema como el nuestro, en el que intentamos dejar las cosas bien claras, aparte de que es GPL, no podría pasar.

Sobre si decidimos agrupar claves por ficheros, pues evidentemente se perdería la granularidad de la seguridad. Pero, es que todo no puede ser ;)
Israel E. Bethencourt
FidoX/CORE
[ Padre ]

Configuraciones gráficas | 27 comentarios (27 temáticos, editoriales, 0 ocultos)

Menu

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

Login


Nueva cuenta
Usuario:
Contraseña:

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