Estructura de el Sistema de Archivos de Linux\nGrupo de Standard de el Sistema de Archivos [FSSTND]\nTraductor: Israel Barrientos\nMaquetador Linuxdoc-SGML: Antonio Ismael Olea González,\nr1.2, abril de 1996\nEl proceso abierto y distribuido en el cual el sistema operativo Linux se ha desarrollado propicia un rápido crecimiento, tanto del sistema operativo, como de aplicaciones, y distribuciones integradas. Por tanto, existe la necesidad de la estandarización de la estructura del sistema de archivos de Linux. Este documento intenta especificar la localización estándar de archivos y directorios en sistemas Linux. Una estructura del sistema de archivos estandarizada permite a usuarios, desarrolladores, y distribuidores, el obtener componentes del sistema de varias fuentes que trabajarán juntas tan bien como si hubiesen sido desarrolladas bajo un proceso de desarrollo centralizado. Ésto también facilita la administración del sistema, así como el desarrollo de paquetes de segundas y terceras personas, y la escritura de documentación que no depende de la implementación.\nLinux no es una Marca Registrada y no tiene conexión con UNIX\nHP-UX es una marca registrada de Hewlett-Packard.\nNovell y Novell NetWare son marcas registradas de Novell.\nSunOS Sun Microsystems, Sun NIS, Sun RPC, y NFS son marcas registradas de Sun Microsystems.\nSystem V y SVR4 son marcas registradas de AT&T.\nX Windows System es una marca registrada de el X Consortium, Inc.\nTodos los otros copyrights son de los propietarios, a menos que se especifique otra cosa .\nEl uso de cualquier término en este documento no debería ser tomado como que afecte la validez de una marca registrada o servicio registrado.\nSe permite la distribución y copia de este estándar siempre que se preserve este copyright y este mensaje en todas las copias.\nSe permite a los participantes y contribuyentes de la FSSTND copiar y distribuir versiones modificadas de este estándar para propósitos de las actividades de estandarizacion del sistema de archivos solamente, bajo las condiciones abajo especificadas. Todas las copias o porciones de este documento deben identificar el titulo del documento y la sección, y deben acompañar este aviso en un lugar prominente.\nNinguna porción de este documento puede ser redistribuida en una forma modificada o recortada sin la aprobación previa de el coordinador del FSSTND. Cualquier entidad que busque permiso para distribuir cualquier material derivado de este documento (Que no sean copias idénticas) debe de contactar al coordinador del FSSTND para la licencia apropiada.\n2.1 Estatus del Estándar\nÉsta es la versión 1.2 de la Estructura del Sistema de Archivos de Linux (Linux Filesystems Structure) FSSTND\nLas guías de este estándar están sujetas a cambio. El uso de la información contenida en este documento es bajo su propio riesgo.\nGeneral: incluyendo un enunciado de enfoque, problemas, objetivos, y requerimientos de conformidad. ( Sección 1).\nEl Sistema de Archivos: Un enunciado de algunos principios guías. ( Sección 2).\nEl Directorio raíz /: ( Sección 3).\nLa jerarquía /usr: ( Sección 4).\nLa jerarquía /var: ( Sección 5).\nRazonamientos adicionales y asuntos sin resolver ( Sección 6).\n3.1 Convenciones Tipográficas\nLa fuente tipo courier se usa para los nombres de archivos y directorios.\nLos componentes de nombres de archivos que varían son representados por una descripción del contenido encerrada entre los caracteres " < " y " > ". Las direcciones de correo electrónico están también encerradas entre " < " y " > " pero se muestran en la fuente usual.\nLos componentes adicionales de los nombres de los archivos se encierran entre los caracteres " [ " y " ] " y pueden ser combinados con la convención " < " y " > ". Por ejemplo, si existe un archivo que puede ser encontrado con o sin extensión, éste podría ser representado por <nombre>[.extensión].\nLas subcadenas variables de los nombres de archivos y directorios se indican con " * ".\nEste documento especifica una estructura estándar del sistema de archivos para los sistemas Linux, incluyendo la localización de archivos y directorios, y el contenido de algunos archivos de sistema.\nEl estándar de sistema de archivos ha sido diseñado para ser usado por desarrolladores de distribuciones, desarrolladores de paquetes e implementadores de sistemas. De cualquier forma está hecho para ser una referencia y no es un tutorial de como manejar un sistema de archivos Linux ó jerarquía de directorios.\nÉstos son algunos de los problemas fundamentales que motivaron originalmente el esfuerzo de estandarización. No había una estructura única, bien aceptada estructura de directorios Linux, en su lugar había muchas estructuras cada una incompatible con las demás. Las jerarquías más ampliamente usadas no estaban bien estructuradas y diferían bastante de las estructuras de directorios modernas "estándares" (tales como System V, BSD, SunOS, y otras). El sistema de archivos era poco familiar e incómodo para los usuarios de UNIX con experiencia y los administradores que habían tenido experiencia con otros sistemas operativos similares a UNIX. La falta de regularidad también confundía a los recién-iniciados en Linux, especialmente aquellos que no tenían un conocimiento previo de UNIX. Cualquier incompatibilidad entre las distribuciones primarias de Linux y los paquetes de aplicación se resolvían por métodos de una naturaleza poco elegante. Los enlaces simbólicos(symbolic links) eran usados demasiado frecuentemente para arreglar los problemas. (De todas maneras, hay veces en las que los enlaces se usan para asegurar compatibilidad hacia atrás o para permitir a algunos sistemas específicos que tengan un sistema de archivos individual y muy particular).\nEn cualquier esfuerzo de estandarización surgen diferencias de opinión. La necesidad del consenso y la práctica común dentro de la comunidad de Linux deben opacar estas diferencias.\nEste estándar del sistema de archivos fue primeramente desarrollado dentro de la lista de correo FSSTND y previamente, en el canal FSSTND de la lista de correo de los LINUX-ACTIVISTS. Los comentarios y recomendaciones fueron recibidos de un gran numero de desarrolladores de Linux, notables programadores de Linux, administradores de sistemas y usuarios. Estos voluntarios quienes han contribuido extensivamente al estándar están listados en el final de este documento. Este estándar representa la visión en consenso de éstos y otros contribuyentes.\nEste estándar busca atacar los problemas estos problemas con una estructura de sistema de archivos bien diseñada que esperamos que la comunidad Linux seguirá voluntariamente. Aunque este estándar comprende más y es más completo que cualquier anterior intento de estandarización, lo más seguro es que nunca esté verdaderamente terminado. Las necesidades de la comunidad Linux cambiarán continuamente debido a las tecnologías emergentes. Es también muy posible que se descubran mejores soluciones a los problemas que nosotros atacamos o que las soluciones que nosotros ahora proponemos dejen de ser las mejores es por eso que el FSSTND planea publicar suplementos y actualizaciones periódicas a este documento.\nLos comentarios relacionados con este documento se agradecen y son bienvenidos por el grupo FSSTND. Cualquier comentario o sugerencia de cambio deberá ser dirigida a al coordinador del FSSTND o si lo prefiere, cualquier coordinador listado en este documento. Los comentarios tipográficos o gramáticos deberán ser dirigidos a el coordinador FSSTND.\nExiste también una FAQ mantenida por Ian McCloghrie, que responde algunas de las preguntas más frecuentemente hechas acerca de este estándar. Si desea implementar el FSSTND o si tiene alguna pregunta por favor lea antes el FSSTND FAQ. Ésta está disponible vía ftp anonymous en tsx-11.mit.edu en el directorio /pub/linux/docs/linux-standards/fsstnd/FSSTND-FAQ.\nPor favor no mande correo a la lista de correo sin antes contactar a el coordinador del FSSTND o a un colaborador listado. Los mensajes impropios no van a ser bien recibidos en la lista.\nPreguntas de como interpretar ciertos artículos en este documento pueden ocasionalmente hacerse, si tiene necesidad de aclarar algún punto, por favor contacte al coordinador. Dado que este estándar representa el consenso de muchos participantes es importante asegurarse que cierta interpretación es también el consenso de su opinión colectiva. Por esa razón puede no ser posible una respuesta inmediata a menos que la pregunta halla sido objeto de discusión previa.\nEl coordinador del FSSTND es Daniel Quinlan <Daniel.Quinlan@linux.org>\n4.2 Problemas específicos.\nNaturalmente, existían ciertos problemas específicos que tratábamos de corregir cuando estandarizamos la estructura del sistema de archivos de Linux, estos son algunos de los más obvios y más grandes. Los directorios binarios principales /bin y /usr/bin no tienen divisiones bien definidas entre ellos. Como resultado la distribución de los binarios entre estos dos directorios varía grandemente entre en cada distribución de Linux. Al incluir ambos, los archivos binarios y los de configuración en /etc hace más confuso este directorio y más difícil de mantener para ambos, el administrador de sistema y el usuario inexperto (especialmente aquellos con sistemas grandes) La división entre lo que debe ser un archivo de configuración específico de un site, y lo que es un archivo de configuración local de una máquina es difícil de establecer. Muchas implementaciones comunes de /usr no pueden ser montadas sólo-lectura debido a que contienen archivos variables y directorios a los cuales se necesita escribir En un ambiente en red es deseable servir software a las estaciones de trabajo vía NFS. Tales sistemas de archivos pueden necesitar ser montados sólo-lectura, para que los accidentes o malicia deliberada desde un estación de trabajo no puedan dañar los archivos en el servidor. Ésto requiere la identificación y la separación de los archivos a los que una máquina debe escribir y los que son específicos de una máquina. Las estructuras de los sistemas de archivos Linux tradicionales no eran muy adecuadas para instalaciones en red, las cuales podrían requerir que componentes sólo-lectura dentro del sistema de archivos ( principalmente en la jerarquía /usr ) o involucrar estaciones sin discos.\nMientras que algunos de los mayores problemas fueron atacados, surgieron numerosos y adicionales que necesitan ser resueltos. Este estándar intenta atacar muchos de estos problemas, pero puede haber algo que fue pasado por alto. Si desea traer algo a nuestra atención, por favor note que hubo asuntos que se han discutido largamente y que no fueron incluidos en este estándar.\nAl tratar de resolver los problemas arriba mencionados, se identificaron varios objetivos que necesitaban ser alcanzados en adición a los problemas más técnicos. Estas metas comprenden la corrección de problemas sobresalientes así como la validación de este estándar.\nResolver los problemas listados antes, y al mismo tiempo limitar las dificultades transicionales mientras se traslada desde los antiguos estandartes de facto. Ganar la aprobación de los distribuidores, desarrolladores y otra gente importante en la comunidad Linux, así como alentarlos a que compartan con nosotros sus sugerencias. Proveer un estándar que la comunidad Linux escoja seguir por que resuelve los problemas anteriores y provee la más sensata estructura de sistemas de archivos de las instalaciones Linux.\nAlgunos de estos objetivos se han completado total o parcialmente debido a la distribución limitada de este documento (en borrador) al distribuidor o desarrollador que solicitó alguno.\nEl mensaje original que motivó este esfuerzo para reestructurar el sistema de archivos Linux fue escrito por Olaf Kirsh <okir@monad.swb.de> el 02 de Agosto de 1993 en el entonces canal NORMAL de la lista de correo de los LINUX-activists.\nEn corto tiempo se decidió que la mejor manera para acometer la necesaria reestructuración de el sistema de archivos de Linux sería la creación de una lista de correo separada con el fin de desarrollar un standard de consenso.\nDespués de una discusión comprensiva y con muy pocas discordias un borrador preliminar fue emitido, con la ayuda de algunas personas dedicadas, el borrador fue terminado y el borrador resultante sometido a consideración en el canal FSSTND para mayor discusión.\nEl primer borrador fue emitido al canal el 18 de Septiembre de 1993 por Daniel Quinlan.\nAl tiempo que la discusión continuaba y los borradores de las recomendaciones de el FSSTND se desarrollaban más, se establecieron contactos con los desarrolladores más accesibles quienes entonces ofrecieron su apoyo y comentarios a nuestro esfuerzo.\nMuchos desarrolladores de Linux estuvieron de acuerdo en que este esfuerzo de estandarización valía la pena y lo apoyaron.\nA continuación estan algunos de los desarrolladores que intentan seguir el estándar FSSTND, parcial o completamente, listados en orden alfabético:\nPRO/ Fred N van Kempen et al. <waltje@infomagic.com>\nRik Faith, Kevin E. Martin, y Doug L. Hoffman <linux-bogus@cs.unc.edu>\nIan A. Murdock <imurdock@debian.org>\nWerner Almesberger <almesber@nessie.cs.id.ethz.ch>\nOwen LeBlanc <LeBlanc@mcc.ac.uk>\nRed Hat Software LINUX (RHS LINUX)\nPatrick J. Volkerding <volkerdi@mhd1.moorehead.msus.edu>\nDave Safford <dave.safford@net.tamu.edu>\nAdam J. Richter <adam@yggdrasil.com>\nEsta sección define los términos "conforme" y "compatible" con respecto a este estándar, y el de " "parcialmente" conforme y compatible.\nUna "implementación" aquí se refiere a una distribución, un sistema instalado, un programa, un paquete ( o alguna pedazo similar de software o datos), o algún componente de ellos.\nUna implementación es totalmente conforme con este estándar si cada requerimiento en este estándar es cubierto. Cada archivo o directorio que sea parte de la implementación debe estar localizado como se especifica en este documento. Si el contenido de un archivo es descrito aquí, el contenido actual debe corresponder con el de la descripción. La implementación también debe intentar encontrar a los archivos o directorios (externos a sí mismo) primeramente o exclusivamente en el lugar especificado en este estándar.\nUna implementación es totalmente compatible con este estándar si cada archivo o directorio que contiene puede ser encontrado viendo en el lugar especificado aquí, aún cuando este no sea el lugar primario o el lugar físico del archivo o directorio en cuestión. La implementación debe, cuando intente encontrar cualquier archivo o directorio que no sea parte de sí, en el lugar especificado en este estándar, aunque también puede intentar encontrarlos en otros lugares no-estándar.\nUna implementación es parcialmente conforme o compatible si cumple con o es compatible con un subconjunto significante de este documento. La conformidad o compatibilidad parcial se aplica solamente a distribuciones y no a programas separados. La frase subconjunto significante es deliberadamente subjetiva y en casos marginales, la parte interesada deberá contactar al coordinador del FSSTND. Se anticipa que cierta variación será tolerada en casos marginales.\nPara calificar como parcialmente conforme con FSSTND o parcialmente compatible con FSSTND, una implementación debe de proporcionar una lista de lugares en los cuales ella y el FSSTND difieren, junto con una nota breve explicando la razón de la discrepancia. Esta lista deberá de ser provista con la distribución en cuestión y deberá estar disponible para la lista FSSTND o el coordinador del FSSTND.\nLos términos "tiene que ", "debe", "contiene", "es" y demás deben ser leídos como requerimientos para la conformidad o compatibilidad.\nNote que una implementación no necesita contener todos los archivos y directorios especificados en este estándar para ser conforme o compatible. Sólo es necesario que aquellos archivos y directorios que sí contiene, que estén localizados apropiadamente. Por ejemplo si el sistema de archivos ext2 no está soportado por una distribución, las herramientas ext2 no necesitan estar incluidas, aunque se mencionen explícitamente en la sección sobre /sbin.\nMás aún, ciertas porciones de este documento son opcionales. En este caso se enunciará explícitamente, o se indicará con el uso de una o más de las palabras " puede", "se recomienda" o "se sugiere" . Los artículos marcados como opcionales no tienen influencia en la conformidad o compatibilidad de una implementación, sólo son sugerencias pensadas para motivar la práctica común, pero pueden estar localizados en cualquier lugar a juicio del implementador.\n5. El sistema de Archivos\nUna estructura jerárquica.\nUn tratamiento consistente de la informacion de los archivos.\nProteccion de los archivos.\nEste estándar del sistema de archivos Linux sigue el mismo principio basico que la mayoría de los sistemas de archivos UNIX siguen. Note, sin embargo que este estándar no intenta concordar en cada aspecto posible con alguna implementacion particular del sistema UNIX. De cualquier forma, muchos de los aspectos de este estándar estan basados en ideas encontradas en UNIX y sistemas similares a UNIX.\nEs posible después de cuidadosa consideracion de otros factores, incluyendo:\nPrácticas comunes en la comunidad Linux.\nLa implementación de otras estructuras de sistemas de archivos.\nLos estándares aplicables.\nDefinir dos categorizaciones ortogonales de archivos: Compartibles vs. no compartibles, y variables vs. estaticos.\nLa informacion compartible es aquella que puede ser compartida entre varias máquinas diferentes; la no compartible es aquella que debe ser local a una máquina particular. Por ejemplo. Los directorios hogar de los usuarios son compartibles, pero los archivos de bloqueo de dispositivo (lock files) son no compartibles.\nLa información estática incluye binarios, librerias, documentación y todo aquello que no cambia sin la intervención del administrador del sistema. La informacion variable es todo lo que cambia sin la intervención del administrador.\nEl entendimiento de estos principios básicos ayudará a guiar la estructura, a lo largo de este documento, y en cualquier sistema de archivos bien planeado, esto brindará consistencia adicional.\nLa distinción entre información compartible y no compartible es necesaria por varias razones:\nEn un ambiente de red (i.e. más de un host en un site), existe una buena cantidad de información que se puede compartir entre diferentes máquinas para ahorrar espacio y facilitar la tarea de administración.\nEn un ambiente de red, ciertos archivos contienen información específica a una sola máquina, por tanto, estos sistemas de archivos no pueden ser compartidos (sin tomar medidas especiales).\nLas implementaciones de facto del sistema de archivos no permitían que la jerarquía /usr fuera montada sólo-lectura, porque contenía archivos y directorios que nesecitaban ser escritos muy frecuentemente. Éste es un factor que debe atacarse cuando algunas partes de /usr se comparten en una red, o se montan sólo-lectura debido a otras consideraciones tales como la seguridad.\nLa distincion "compartible" puede ser usada para soportar, por ejemplo:\nLa distincion "estática" contra "variable" afecta el sistema de archivos de dos maneras principales:\nDado que / contiene ambos tipos de información, variable y estática necesita montarse lectura-escritura.\nDado que el /usr tradicional contiene ambos tipos de información variable y estática y dado que podríamos desear montarlo sólo-lectura (vea arriba), es necesario proporcionar un método para hacer que /usr se monte sólo-lectura. Ésto se logra con la creación de una jerarquía /var que se monta lectura-escritura (o es parte de una partición lectura-escritura tal como /), que toma mucho de la funcionalidad tradicional de la particion /usr.\n5.1 Tabla con ejemplos.\nCompartibleNo-CompartibleEstática/usr/etc/home/bootVariable/var/spool/mail/var/run/var/spool/news/var/lock3. El directorio raíz /. Esta sección describe la estructura del directorio raíz. El contenido del sistema de archivos raíz será el adecuado para arrancar, bootear, restaurar,recuperar y/o reparar el sistema:\nPara arrancar el sistema, debe estar presente lo suficiente como para montar /usr y otras partes no-esenciales del sistema de archivos. Ésto incluye herramientas, información de configuración y del cargador de arranque (boot loader) y alguna otra información esencial al arrancar.\nPara habilitar la recuperación y/o la reparación del sistema, estará presente en el sistema de archivos raíz aquellas herramientas que un administrador experimentado necesitaría para diagnosticar y reconstruir un sistema dañado.\nPara restaurar un sistema, estarán presentes en el sistema de archivos raíz aquellas herramientas necesarias para restaurar el sistema desde respaldos (en floppy, cintas, etc).\nLa principal preocupación que se usa para balancear las anteriores consideraciones, que favorecen el colocar muchas cosas en el sistema de archivos raíz, es la meta de mantener / tan pequeno como sea razonablemente posible. Por varias razones es deseable mantener el sistema de archivos /\nEs frecuentemente montado desde media muy pequena. Por ejemplo muchos usuarios de Linux instalan y recuperan sistemas montando / como un disco ram, que es copiado de un disco de 1.44Mb único.\nEl sistema de archivos / tiene muchos archivos de configuración específicos de un sistema. Posibles ejemplos son un kernel que es específico al sistema, un hostname diferente, etc. Ésto significa que el sistema de archivos / no es siempre compartible entre sistemas en red. Manteniéndolo pequeño en sistemas en red, se minimiza el espacio perdido en los servidores por archivos no-compartibles. También permite estaciones de trabajo con discos duros locales más pequeños.\nAunque usted podría tener el sistema de archivos / en una partición grande, y ser capaz de llenarla según sus deseos, siempre habrá gente con particiones más pequeñas. Si usted tiene más archivos instalados, podría encontrar incompatibilidades con otros sistemas que utilizan un sistema de archivos / en particiones más pequeñas. Si usted es un desarrollador entonces estaría volviendo su suposición en un problema para un gran número de usuarios.\nLos errores del disco, que corrompen la información en el sistema de archivos / son un problema mayor que los errores en cualquier otra partición. Un sistema de archivos / pequeño es menos propenso a corromperse como resultado de una falla del sistema.\nEn este documento, actualmente se requiere un sistema de archivos / escribible (debido principalmente a /etc/mtab). De cualquier forma, no se necesita que el sistema de archivos / esté totalmente almacenado localmente. La partición / no tiene porque estar almacenada localmente para ser específica del sistema por ejemplo, podría estar montada de un servidor NFS.\nEl software no deberá crear o requerir archivos o subdirectorios especiales en el directorio /. La estructura del sistema de archivos Linux proporciona más que suficiente flexibilidad para cualquier paquete. Cualquier paquete que ocupe un directorio bajo la raíz / del sistema de archivos sufre de bastante arrogancia.\n5.2 El Directorio Raíz\nboot            Archivos estáticos de cargador de arranque(boot-loader)\netc             Configuración del sistema local-máquina\nlib             Librerías compartidas\nusr             Segunda jerarquía mayor\nvar             Información variable\nCada directorio listado será discutido en detalle en una subsección separada más delante. /usr y /var, cada uno tiene en su propia sección en este documento.\nEl kernel de Linux estaría localizado en, ya sea / ó en /boot. Si está localizado en / recomendamos usar el nombre VMLINUX o VMLINUZ, nombres que han sido usados en paquetes fuentes del kernel de Linux recientes. Más información de la localización del kernel se puede encontrar en la sección acerca de / más delante.\n5.3 /bin Binarios de comandos esenciales de usuarios (disponibles para todos los usuarios).\nbin contiene comandos que pueden ser utilizados por ambos los usuarios y /el administrador del sistema, pero que son requeridos en el modo /mono-usuario (single-user mode) puede también contener comandos que son /utilizados indirectamente por algunos scripts.\nTodos los binarios utilizables sólo por root, tales como daemons,init,getty, update, etc. Estarían localizados en /sbin ó /usr/sbin dependiendo si son o no esenciales. Para una mayor discusión de la definición de que es esencial en el sistema de archivos /, lea por favor la sección 6, "Razonamientos adicionales y asuntos sin resolver".\nLos binarios de los comandos que no son suficientemente esenciales para estar en /bin estarán localizados en /usr/bin, los elementos que son utilizados por usuarios solamente (pero no por root) (mail,chsh, etc) no son suficientemente esenciales para estar dentro de la partición /.\nLos siguientes comandos han sido incluidos porque son esenciales. algunos están presentes debido a que tradicionalmente han estado en /bin.\nSi /bin/sh es Bash, entonces /bin/sh sería en enlace simbólico o duro a /bin/bash dado que bash se comporta diferente cuando es llamado como sh ó bash. La pdksh que puede ser la /bin/sh en los discos de instalación y sería igualmente arreglada a que /bin/sh sea un enlace simbólico a /bin/ksh. El uso de enlaces simbólicos en estos casos permite que los usuarios vean fácilmente que /bin/sh no es una shell estilo bourne.\nDado que la localización estándar de facto de shell estilo c es /bin/csh,si y sólo si está disponible en el sistema una shell estilo c ó equivalente (tal como /bin/tcsh, esta, estaría disponible con el nombre /bin/csh. /bin/csh puede ser un enlace simbólico a /bin/tcsh ó /usr/bin/tcsh).\nLos comandos [ y test están interconstruidos en bash, pdksh, zsh, y las shell korn recientes, esencialmente cada remplazo de las shell tipo bourne que hay para Linux. Estos comandos estarían localizados dentro de /usr/bin. (se deben incluir como binarios separados con cualquier sistema Linux que intente cumplir con el estándar POSIX).\nbin/arch produciría el mismo resultado que uname-m, especificamente; 386 /o; 486 para sistemas intel y compatibles.\nEstos comandos se han incluido para hacer posible el restaurar el sistema(siempre que / este intacto).\nSi se hacen respaldos de sistemas utilizando otros programas, entonces la particion / contendrá los componentes mínimos necesarios. Por ejemplo,muchos sistemas incluirían cpio como la segunda utilería más usada para respaldos después de tar. Pero si jamás se espera restaurar el sistema desde la partición /, entonces estos binarios se pueden omitir (i.e.,montar / en chip ROM, montar /usr desde NFS). Si la restauración del sistema se planea a traves de la red, Entonces FTP ó TFTP (junto con todo lo necesario para obtener una conexión FTP) estarían disponibles en la partición /.\nLos comandos de restauración pueden aparecer en, ya sea /bin ó /usr/bin en sistemas Linux diferentes.\nEste directorio contiene todo para arrancar excepto los archivos de configuración y el instalador de mapas. En su sentido más sencillo /boot es para cualquier cosa que se utiliza antes de que el kernel ejecute /sbin/init. Ésto incluye sectores maestros de arranque (master boot sectors) guardados, archivos de mapeo de sectores y cualquier otra cosa que no es editada directamente a mano.Los programas necesarios para arreglar que el cargador de arranque sea capaz de arrancar un archivo (tal como el instalador de mapas [lilo] ) estarán localizados en /sbin. Los archivos de configuración para cargadores de arranque podrían estar localizados en /etc.\nComo se expuso arriba, el kernel de Linux puede estar localizado en / ó en /boot, si se localiza en /boot, recomendamos que se le dé un nombre más descriptivo.\nÉste es el directorio de los dispositivos. Contendría un archivo por cada dispositivo que el kernel de Linux puede soportar.\ndev también contiene un script llamado MAKEDEV el cual puede crear /dispositivos cuando se necesiten. Puede contener un MAKEDEV local para /dispositivos sólo-local.\nMAKEDEV debe hacer previsión para crear cualquier archivo de dispositivo especial listado en la lista de numeros mayores/menores, no sólo aquellos de una distribución particular.\nLos enlaces simbólicos no se deben distribuir en sistemas Linux, sino sólo como se preveé en la lista de dispositivos de Linux. Ésto es porque las instalaciones locales seguro diferirán de aquellas de la máquina del desarrollador. Ademas si un script de instalación configura enlaces simbólicos en la instalación, estos enlaces seguramente no se actualizarán si se hacen cambios locales en el hardware. Cuando se usan responsablemente,como sea, son de buen uso.\nEste documento incorpora como referencia la lista de dispositivos de Linux, mantenida por: Peter.Anvin@linux.org: El encargado de los dispositivos Linux.Todos los archivos especiales de dispositivo seguirán el estándar en ese documento, que está disponible en ftp.yggdrasil.com en /pub/device-list.\n5.6 /etc : Configuración del sistema local a la máquina.\nNingún binario debe ir directamente dentro de /etc. Los binarios que en el pasado se encontraban en /etc, irán en /sbin ó /usr/sbin. Ésto incluye archivos tales como init, getty y update. Los binarios tales como hostname que son utilizados por usuarios ordinarios y por root no irían en /sbin sino en /bin.\n/etc --- Configuracion de sistemas locales de máquina.\netc/skel es la localidad para los llamados archivos esqueletos de /usuarios, que le son dados por defecto cuando un nuevo usuario recibe una /cuenta, este directorio puede contener subdirectorios para diferentes /grupos de usuarios (i.e./etc/skell/apoyo, /etc/skell/usuarios).\netc/X11 es el lugar recomendado para todos los archivos de configuración /de X11 locales a la máquina. Este directorio es necesario para permitir el /control local si /usr se monta sólo-lectura. Los archivos que deben ir en /este directorio incluyen Xconfig (y/o XF86Config) y Xmodmap.\nLos subdirectorios de /etc/X11 pueden incluir aquellos para xdm y para cualesquier otros programas (como algunos manejadores de ventanas por ejemplo) que lo necesiten. Recomendamos que los manejadores de ventanas con un solo archivo de configuración que es un archivo .*wmrc por defecto, que lo llamen system.*wmrc (a menos que exista una alternativa ampliamente aceptada) y que no utilize un subdirectorio. Cualquier subdirectorio de un manejador de ventanas se llamaría idéntico al binario del manejador de ventanas.\netc/X11/xdm retiene los archivos de configuración de xdm. Ésto es la /mayoría de los archivos normalmente hallados en /usr/lib/X11/xdm; Vea la /seccion 5,/var/lib/xdm, para mayor información.\nLa siguiente sección intenta parcialmente examinar la descripción del contenido de /etc con algunos ejemplos: Definitivamente ésta no es una lista exhaustiva.\nArchivos de Red:\nEstos archivos estarían instalados en la mayoria de los sistemas Linux.\nHay dos modelos para la instalación de los scripts de comandos "rc" los cuales son invocados por init(8) al momento de arrancar, el modelo /etc/rc.d/* estilo SystemV. Cualquiera puede ser utilizado o una mezcla de los dos.\nLos sistemas con la suite de passwords sombreadas (shadow password) tendrán archivos de configuración adicionales, en /etc (/etc/shadow y otros) y /usr/bin (useradd, usermod, y otros).\n5.7 /home: Directorios hogar de los usuarios (opcional)\nhome es un concepto algo estándar, pero es claramente un sistema de /archivos específico de un site. El arreglo diferirá de máquina a máquina. /Esta sección describe una localización sugerida para los directorios hogar /de los usuarios, aun así, recomendamos que todas las distribuciones /Linux usen este lugar como la localización por defecto de los /directorios hogar.\nEn sistemas pequeños, cada directorio de usuario es uno de los subdirectorios debajo de /home, p.ej. /home/smith, /home/torvalds, /home/operador, etc.\nEn sistemas grandes (especialmente cuando los directorios /home son compartidos entre varias máquinas usando NFS) es útil subdividir los directorios hogar. La subdivisión puede ser llevada a cabo utilizando subdirectorios tales como /home/apoyo, /home/huéspedes, /home/estudiantes, etc.\nMuchas personas prefieren poner las cuentas de los usuarios en una variedad de lugares. Por tanto, ningún programa deberá confiar en esta localización. Si usted desea encontrar el directorio hogar de cualquier usuario, debería usar la función de librería getpwent(3) en vez de contar con /etc/passwd, por que la información puede estar almacenada remotamente usando usando sistemas como NIS.\n5.8 /lib: Librerías compartidas y módulos de kernel escenciales\nEl directorio /lib contiene aquellas imágenes de las librerías compartidas que se necesitan para arrancar el sistema y ejecutar los comandos en el sistema de archivos raíz.\nlib --- librerías compartidas y modulos de kernel esenciales.\nmodules Modulos de kernel cargables.\nEsto incluye /lib/libc.so.*, /lib/libm.so.*, el enlazador dinámico compartido /lib/ld.so.*, y otras librerías compartidas requeridas por binarios en /bin y /sbin.\nLas librerías que son necesitadas sólo por los binarios en /usr (como cualquier binario de X Window) no pertenecen a /lib. Sólo las librerías compartidas requeridas para ejecutar los binarios dentro de /bin y /sbin deben estar aquí. La librería libm.so.* podría estar localizada en /usr/lib si no es requerida por nada en /bin ó /sbin.\nPor razones de compatibilidad, /lib/cpp necesita existir como una referencia al pre-procesador C instalado en el sistema. La localización usual del binario es /usr/lib/gcc-lib/<target>/<version>/cpp. Puede existir un enlace/lib/cpp apuntando a este binario o a cualquier otra referencia a este binario que exista en el sistema de archivos. (Por ejemplo, /usr/bin/cpp se usa frecuentemente).\nLa especificación para /lib/modules está aún por aparecer.\n5.9 /mnt: Punto de montaje para sistemas de archivos montados temporalmente.\nEste directorio se ha provisto para que el administador pueda montar temporalmente sistemas de archivos cuando lo necesite. El contenido de este directorio es un asunto local y no debe afectar la manera en la cual se ejecuta ningún programa.\nRecomendamos la no utlización de este directorio por programas de instalación, y sugerimos utilizar un directorio temporal adecuado que no este en uso por el sistema.\nEl sistema de archivos proc se está convirtiendo en el estándar de facto para el manejo de informacion de procesos y de sistema en vez de /dev/kmem y otros metodos similares. Recomendamos fuertemente esto para el almacenamiento y obtención de información de procesos asi como otra información del kernel y de memoria.\n5.11 /root: Directorio hogar de root (opcional)\nEl directorio / es tradicionalmente el directorio hogar del usuario root en los sistemas UNIX. /root se usa en muchos sistemas Linux y en algunos sistemas UNIX. El directorio hogar de la cuenta de el usuario root puede ser determinada por el desarrollador o por preferencias locales. Las posibilidades obvias incluyen /, /root, y /home/root.\nSi el directorio hogar de root no está almacenado en la partición raíz, será necesario asegurarse que tome / por defecto si no puede ser localizado.\nNOTA: Recomendamos contra el uso de la cuenta root para cosa mundanas tales como leer el correo y ver las noticias (mail & news) sino que se use solamente para la administración del sistema. Por esta razón recomendamos que no aparezcan subdirectorios como Mail y News en el directorio hogar de la cuenta del usuario root. Recomendamos que el Mail para root y postmaster sean redirigidos a un usuario más adecuado.\nLos útiles usados por la administración del sistema ( y otros comandos que sólo root utiliza ) están almacenados en /sbin, /usr/sbin, y /usr/local/sbin. /sbin típicamente contiene binarios escenciales para arrancar el sistema ademas de los binarios en /bin. Cualquier cosa que se ejecuta después de que se sabe que /usr se ha montado (cuando no hay problemas) debería estar en /usr/sbin. Los binarios de administración de sistema sólo-locales deben estar localizados en /usr/local/sbin.\nDecidir que cosa va en los directorios de /sbin es sencillo: Si un usuario necesitará ejecutarlo, debe de ir en otro lado. Si sólo será ejecutado por el administrador del sistema o por root como scripts de administración, entonces debe ir en /sbin (o en /usr/sbin o en /usr/local/sbin, si el archivo no es vital para la operación del sistema).\nArchivos como chfn que los usuarios usan sólo ocasionalmente deben aun estar en /usr/bin. ping aunque es absolutamente necesario para el root (recuperación de la red y diagnóstico) es tambien frecuentemente usado por los usuarios y por esa razon debe ir en /bin.\nLos usuarios ordinarios no tendrán que poner ninguno de los directorios sbin en su búsqueda (path).\nRecomendamos que los usuarios tengan permisos de lectura y ejecución en todo lo que se encuentra en /sbin excepto tal vez ciertos programas; setuid y setgid. La división entre /sbin y /bin no fue creada por motivos de seguridad o para evitar que los usuarios vieran el sistema operativo, sino para proveer una buena partición entre binarios que todos usan y los que se usan, principalmente las tareas de administración. No hay ganancia inherente en seguridad en hacer que /sbin este fuera del alcance de los usuarios.\ndonde * = uno de los siguientes.\next, ext2 minix, msdos, xia, y tal vez otros.\nComandos del sistema de archivos ext2 (opcional)\nln estático sln y sync estático ssync son útiles cuando las cosas salen mal. El principal uso de sln (reparar enlaces simbólicos incorrectos en /lib despues de una actualización mal orquestrada) ya no es preocupación mayor ahora que existe el programa ldconfig (usualmente localizado en /usr/sbin) y puede actuar como una mano guiadora al actualizar las librerías dinámicas. sync estático es útil en algunas ocasiones de emergencia. Note que estas no necesitan ser versiones compiladas estáticamente de los ln y sync estándares, pero pueden ser.\nEl binario ldconfig es opcional en /sbin, dado que un site puede escoger ejecutar ldconfig al arrancar, en vez de sólo cuando se actualizan las librerías compartidas. (No está claro si es o no ventajoso ejecutar ldconfig en cada arranque). Aun así, a algunos les gusta tener ldconfig a la mano para las siguientes (muy comunes) situaciones:\nSe acaba de remover /lib/<archivo>.\nNo se puede encontrar el nombre de la librería porque ls está enlazado dinámicamente. Se está usando una shell que no tiene ls interconstruida y no se sabe como usar "echo * " como remplazo.\nSe tiene un sln, pero no se sabe como nombrar al enlace.\ntmp se utiliza para archivos temporales, preferentemente en un /dispositivo rápido (un sistema de archivos basado en memoria por ejemplo)\nLa "persistencia" de la informacion que es almacenada en /tmp es diferente de aquella que sea almacenada en /var/tmp. /tmp puede ser limpiada en cada arranque o a intervalos relativamente frecuentes. Por tanto, no se debe esperar que la informacion almacenada en /tmp permanezca por algún periodo largo de tiempo.\nLos programas deben utilizar /tmp ó /var/tmp (que era originalmente /usr/tmp) de acuerdo a los requerimientos esperados de la informacion, pero no deben confiar en alguna persistencia temporal particular en cualquier directorio de almacenamiento temporal.\nLos administradores de sistemas pueden elegir enlazar /tmp a algun otro directorio, tal como /var/tmp; esto es útil, por ejemplo, para conservar espacio en la partición raíz. Si ésto se lleva a cabo, entonces la persistencia de archivos en /var/tmp debe ser al menos tan larga como la de /tmp.\ntmp puede estar e un disco RAM. /var/tmp no debe nunca localizarse en /algun dispositivo RAM.\n6. La jerarquía /usr\nusr es la segunda mayor seccion del sistema de archivos. /usr es /informacion compartible, de sólo-lectura, esto significa que /usr, debe ser /compartible entre varias máquinas que corren Linux y no se debe /escribir. Cualquier informacion que es local a una máquina o varía con el /tiempo, se almacena en otro lugar.\nNingun paquete grande (como TeX o GNU Emacs) debe utilizar un subdirectorio directo bajo /usr, en vez, debe haber un subdirectorio dentro de /usr/lib (o /usr/local/lib si fué instalado completamente local) para ese propósito, con el sistema X Window se hace una excepción debido a un considerable precedente y a la práctica ampliamente aceptada.\nbin             La mayoría de los comandos de usuario\ndoc             Documentación miscelánea\netc             Configuración del Sistema (todo el site)\nlocal           Jerarquía local (vacía justo después de la instalación principal)\nman             Manuales en línea\nsbir            Binarios de Administración del Sistema No-Vitales\nshare           Información independiente de la arquitectura\nsrc             Código fuente\nLos siguientes enlaces simbólicos a directorios pueden estar presentes. Esta posibilidad se basa en la necesidad de preservar la compatibilidad con sistemas anteriores hasta que en todas las implementaciones se pueda asumir el uso de la jerarquía /var.\n/usr/adm  ------------------>  /var/adm\n/usr/preserve  ------------->  /var/preserve\n/usr/spool  ---------------->  /var/spool\n/usr/tmp  ------------------>  /var/tmp\n/var/spool/locks  ---------->  /var/lock\nUna vez que el sistema ya no requiera más alguno de los anteriores enlaces simbólicos, el enlace se puede remover, si se desea. Notablemente, sólo se necesita poco esfuerzo para remover completamente /usr/preserve, dado que sólo ex y vi lo utilizan.\n6.1 /usr/X11R6: El sistema X Window, Version 11 release 6\nEsta jerarquía está reservada para el sistema X Window, Version 11 release 6 y archivos relacionados.\nPara simplificar los problemas y hacer XFree86 más compatible con el sistema X Window en otros sistemas, los siguientes enlaces simbolicos deben estar presentes.\n/usr/bin/X11  ------------>  /usr/X11R6/bin\n/usr/lib/X11  ------------>  /usr/X11R6/lib/X11\n/usr/include/X11  -------->  /usr/X11R6/include/X11\nEn general, el software no se debe instalar o manejar vía los anteriores enlaces simbólicos. Sólo están para la utilización por usuarios. La dificultad está relacionada con la versión y el release del sistema X Window; en períodos transicionales es imposible saber que release de X11 está utilizandose .\nPor la misma razón no debe existir un enlace desde /usr/X11 apuntando a la jerarquía del sistema X Window actual.\n6.2 /usr/X386: El sistema X Window, Version 11 release 5 en plataformas X 86\nEsta jerarquía es generalmente idéntica a /usr/X11R6, excepto que los enlaces simbólicos de /usr deben estar ausentes si está instalado /usr/X11R6\nX11     Enlace simbólico hacia /usr/X11R6/bin\nDebido a que los interpretadores de scripts de los shell (invocados con #! <ruta> en la primera linea del script de shell) no pueden depender de una ruta, es ventajoso el estandarizar la localización de ellos. La shell Bourne y C estan fijos en /bin, pero Perl, Python, Tlc se encuentran en muchos lugares diferentes /usr/bin/perl, /usr/bin/python y /usr/bin/tcl deben referenciar a los intérpretes de shell perl, python y tcl respectivamente. Éstos pueden ser enlaces simbólicos a la localización física de los intérpretes de shell.\n6.3 /usr/dict: Listas de palabras\nArchivos recomendados en /usr/dict\nTradicionalmente este directorio contiene sólo el archivo words de palabras inglesas, el cual es utilizado por look(1) y varios programas de ortografía, words puede utilizar ortografía americana o británica. Los sites que requieran ambos, pueden enlazar words a /usr/dict/american-english ó /usr/dict/british-english.\nLas listas de palabras para otros lenguajes se pueden añadir usando el nombre en inglés para ese lenguaje, por ejemplo, /usr/dict/french, /usr/dict/danish, etc. Éstos deben, si es posible, utilizar un juegos de caracteres ISO 8859 que sea apropiado para el lenguaje en cuestión, si es posible el juego de caracteres ISO 8859-1 (Latin1) debe ser utilizado (esto es a veces imposible)\nCualquier otra lista de palabras, tal como el directorio web2, debe ser incluido aquí, si está presente.\nLas razones tras tener sólo las listas de palabras aquí es que ellas son los únicos archivos comunes a todos los verificadores de ortogafía.\n6.4 /usr/etc: Configuración del sistema (todo el site)\nAlmacenar la configuración en /usr/etc del software que se encuentra en /usr/bin y /usr/sbin es un problema. Hace que el montar /usr sólo-lectura de un CDROM o a través de NFS sea difícil en el mejor de los casos.\nUna posible solución que se consideró fue eliminar completamente /usr/etc y especificar que todas las configuraciones se almacenen en /etc. Un problema con esta aproximación es que no anticipa propiamente la posibilidad de que muchos sites pueden querer tener algunos archivos de configuracion que no sean locales de máquina.\nEventualmente se decidió que /etc deberá ser el único directorio que sea referenciado por los programas (esto es, todos deben buscar configuraciones en /etc y no en /usr/etc). Cualquier archivo de configuración que necesite ser para todo el site y que no es necesario antes de montar /usr (o en una situación de emergencia debe entonces estar localizado en /usr/etc. Entonces archivos específicos (en /etc), en máquinas específicas pueden ser o no ser enlaces simbólicos a los archivos de configuración localizados en /usr/etc. Ésto también significa que /usr/etc es técnicamente un directorio opcional en el sentido estricto, pero aún así recomendamos que todos los sistemas Linux lo incorporen.\nNo se recomienda que /usr/etc contenga enlaces simbólicos que apunten a archivos en /etc. Ésto es innecesario e interfiere con el control local en máquinas que comparten un directorio /usr.\n6.5 /usr/include: Directorio para archivos include estándar.\nAquí es donde todos los archivos include de uso general del sistema para programación en lenguajes C y C++ deben ser localizados.\nX11             Enlace simbólico hacia /usr/X11R6/include/X11\nasm             Enlace simbólico hacia /usr/scr/linux/include/asm-<arch>.\nnet             Definiciones genéricas relacionadas con redes.\nnetax25         Definiciones específicas a  +AX25 ( ARRL AX25).\nnetinet         Definiciones específicas a  TCP/IP.\nnetipx          Definiciones específicas a +IPX (Novel IPX/SPX).\nreadline        La librería readline GNU.\nsys             Archivos  include de generación de sistemas.\nEl subdirectorio arpa contiene definiciones de cabecera de protocolos para los protocolos ARPANET, TCP/IP, definiciones para ftp, prototipos telnet y material similar.\nEl subdirectorio net contiene definiciones genéricas relacionadas con redes, define la interface sistema-kernel, detalles de la familia de protocolo, etc.\nEl subdirectorio netinet contiene definiciones especificas de INET (DARPA Internet, que tambien es conocida como TCP/IP )\nARRL AX.25 es mejor conocido como packet radio. Los protocolos novell IPX/SPX son parte de los servicios de archivos Novell Netware.\n6.6 /usr/lib: Librerías para programas y paquetes.\nusr/lib incluye librerías objeto, binarios del programa compilador e /información estática de varias clases, ambos, códigos ejecutable ( por /ejemplo los binarios internos de gcc estan localizados bajo //usr/lib/gcc-lib ) y otros tipos de informacion.\n/usr/lib/ - librerias para programción y paquetes:\nX11             Enlace simbólico a /usr/X11R6/lib/X11\nemacs           Archivos de soporte estáticos para el editor GNUEmacs.\ngames           Archivos de datos estáticos para /usr/games.\ngroff           Librerías / Directorios para GNU groff\ngcc-lib         Archivos/ Directorios específicos del sistema para gcc.\nkbd             Tablas de traducción de teclado e información relacionada.\nMh              Librerías para el sistema de manejo de correo MH:\ntexmf           TeX/MF ( y LaTeX ) librerías de información.\nzoneinfo        Configuración e información de la zona horaria.\nHistóricamente, /usr/lib ha incluido además algunos comandos ejecutables tales como sendmail y makewhatis.\nDado que makewhatis no es referenciado por otros programas, no hay problemas al moverlo a un directorio binario. Dado que los usuarios tienen buena razón para usar makewhatis, /usr/lib es donde pertenece. El binario catman que remplaza al script makewhatis en muchos sistemas Linux, debe también estar en usr/bin\nEl binario sendmail es referenciado por muchos programas con su nombre histórico /usr/lib/sendmail. Éste debe ser un enlace simbólico a la localización estándar para los agentes de transferencia de correo con una interfaz de línea de comando compatible con sendmail, /usr/bin/sendmail.\nEn sistemas que utilizan smail deben localizar smail en /usr/sbin/smail y /usr/bin/sendmail debe ser un enlace simbolico a smail.\nEste arreglo también se conforma a la nueva locación estándar sendmail definida en Sendmail 8.6.x y BSD 4.4\nNote que esta localización demanda que /usr/sbin y /usr/sbin/sendmail deben ser ejecutables para usuarios normales.\nCualquier paquete o programa que contenga o requiera información que no necesite ser modificada debe almacenar tal información en /usr/lib ( ó /usr/local/lib, si está instalado localmente ). Se recomienda la utilizacion de un subdirectorio en /usr/lib para este propósito.\nLa información de juegos almacenada en /usr/lib/games debe ser solamente información estática. Cualquier archivo modificable . tal como archivos de marcadores, registros de juego y similares, deben ser localizados en var/lib. Si es necesario para compatibilidad de juegos con el viejo estilo BSD, se puede usar un enlace simbólico desde /usr/games/lib hacia /usr/lib/games.\nNota: ninguna información específica de host para el sistema X window debe almacenarse en /usr/lib/X11 ( que es realmente /usr/X11R6/lib/X11) . Los archivos de configuración específicos de host tales como Xconfig ó XF86Config deben almacenarse en /etc/X11. Éste debe incluir información de configuración como system.twmrc aún si es sólo un enlace simbólico a un archivo de configuración más global ( tal vez en /usr/etc/X11 ó /usr/X11R6/lib/X11).\n6.7 /usr/local: Jerarquía local\nLa jerarquía /usr/local está para ser utilizada por el administrador del sistema cuando se instale el software localmente. Necesita estar a salvo de ser sobreescrito cuando el software del sistema se actualiza. Puede ser usado por programas y por información que son compartibles entre un grupo de máquinas, pero no se encuentran en /usr.\n/usr/local      Jerarquía local.\nbin             Binarios sólo-locales\ndoc             Documentación local\netc             Binarios de configuración sólo-local\nlib             Librerís para /usr/local\ninfo            Páginas de info local\nman             Jerarquías de páginas de manual para /usr/local\nsbin            Administración del sistema sólo-local\nscr             Código fuente local.\nEste directorio debe estar vacío al terminar de instalar Linux por primera vez. No debe haber excepciones a la regla, excepto quizá los subdirectorios vacíos listados.\nEl software instalado localmente debe estar localizado dentro de /usr/local, en vez de /usr a menos que este siendo instalado para reemplazar o actualizar el software en /usr.\nNote que el software localizado en / o en /usr puede ser sobreescrito por actualizaciones del sistema (aunque recomendamos que las distribuciones no sobreescriban informacion en /etc bajo estas circunstancias). Por esta razón, el software local no se debe localizar fuera de /usr/local sin una buena causa.\n6.8 /usr/man : Páginas del manual.\nEsta sección detalla la organización de las páginas del manual a través del sistema. Incluyendo /usr/man.\nLas páginas del manual están almacenadas <mandir>/<locale>/man [1-9]. Más delante se dá una explicación de <mandir> y <locale>.\n<mandir>/<locale> --- Una  jerarquía de páginas de manuales.\nman3            Subrutinas y funciones de librería\nman8            Administración del Sistema.\nEl <mandir> primario del sistema es /usr/man contiene información del manual para comandos e información bajo los sistemas de archivos / y /usr. Obviamente no hay páginas de manual en / por que no se necesitan para arrancar ni en emergencias.\nSe debe hacer provisión en la estructura de /usr/man para el soporte de páginas del manual que estén escritas en diferentes (o multiples idiomas ). Estas provisiones deben tomar en cuenta el almencenamiento y referencia de estas páginas del manual. Los factores relevantes incluyen el idioma ( incluyendo diferencias basadas en la geografia ) y el código del conjunto de caracteres.\nEsta nomenclatura de los subdirectorios de idiomas de /usr/man está basada en el apendice E del estándar POSIX 1003.1 que describe la cadena de identificación locale ---El metodo más aceptado para describir un ambiente cultural. La cadena <locale>es:\nEl campo <idioma> se tomará del ISO639 (un código para la representacion de los nombres de los idiomas). Sera de dos caracteres de ancho y especificado con minúsculas solamente.\nEl campo <_territorio> sera el código de dos letras de ISO3116 (una especificación de la representación de los nombres de los países), si es posible. (mucha gente está familiarizada con el código de 2 letras empleado en el código de país en las direcciones de e-mail.\nEl campo <conjunto_de_caracteres> debe representar el estándar que describe el código de caracteres. Si el campo <conjunto_de_caracteres> es sólo una especificación numérica, el número representa el número del estándar internacional que describe a ese conjunto de caracteres. Se recomienda que este sea una representacion numérica siempre que sea posible (especialmente, estándares ISO), que no incluya símbolos de puntuación y que todas las letras sean minúsculas.\nUn párametro que especifique <version> del perfil puede ser colocada despues del campo <conjunto_de_caracteres >, delimitado con una coma. Ésto puede utilizarse para discriminar entre diferentes necesidades culturales, por ejemplo un orden de diccionario en vez de un orden de acomodo más orientado hacia el sistema. Este estándar recomienda no usar el campo <version> a menos que sea necesario.\nEn sistemas que usen sólo un idioma y un código de conjunto de caracteres para todas las páginas del manual, pueden omitir la subcadena <locale> y almacenar todas las páginas del manual en <mandir>. Por ejemplo en sistemas que sólo tienen páginas del manual en inglés codificados en ASCII, pueden almacenar las páginas del manual (los directorios man[1-9]) directamente en /usr/man (éstas son las circunstancias y el arreglo tradicional, de hecho).\nEn países para los cuales existe un código de conjunto de caracteres estándar, puede omitir el campo <conjunto_de_caracteres>, pero recomendamos fuertemente que se incluya, especialmente para países con varios estándares en competencia.\nInglés           --------        ASCII                   /usr/man/en\nInglés           Reino Unido     ASCII                   /usr/man/en_GB\nInglés           Estados Unidos  ASCII                   /usr/man/en_US\nFrancés          Canadá   ISO8859-1               /usr/man/fr_CA\nFrancés          Francia         ISO8859-1               /usr/man/fr_FR\nAlemán           Alemania        ISO646-DE               /usr/man/de_DE646de\nAlemán           Alemania        ISO6937                 /usr/man/de_DE6937\nAlemán           Alemania        ISO8859-1               /usr/man/de_DE.88591\nAlemán           Suiza           ISO646-CH               /usr/man/de_CH.646ch\nJaponés          Japón            JIS                     /usr/man/ja_JP.jis\nJaponés          Japón            SJCS                    /usr/man/ja_JP.sjis\nJaponés          Japón    UJ (o EUC-J)            /usr/man/ja_JP.ujis\nLas páginas del manual para los comandos e información que se encuentra bajo /usr/local están almacenadas en /usr/local/man. las páginas del manual para el sistema X Window están almacenadas en /usr/X11R6/man. Luego todas las jerarquías de páginas del manual en el sistema deben tener la misma estructura que /usr/man. Los directorios vacíos pueden ser omitidos de la jerarquía de páginas del manual. Por ejemplo si, /usr/local/man no tiene páginas del manual en la sección 4 (dispositivos) entonces se puede omitir /usr/local/man/man4.\nLas secciones de páginas cat (cat[1-9]) que contiene páginas del manual formateadas, también se encuentran dentro de los subdirectorios /<mandir>/<locale>, pero no son requeridas ni deben ser distribuidas en el lugar de las fuentes nroff de las páginas del manual.\nLas páginas del Manual del sistema de manejo de correo mh deben tener el prefijo mh en todos los nombres de archivos de las páginas.\nLas páginas del sistema X Window deben tener el prefijo x en todos los nombres de los archivos de las páginas.\nLa práctica de colocar las páginas del manual de diferentes idiomas, en los subdirectorios apropiados de /usr/man también se aplica a las otras jerarquías de páginas del manual, tales como /usr/local/man, y /usr/X11R6/man.\n(Esta porción de este estándar tambien se aplica más delante en la estructura opcional de /var/catman).\nA continuación una descripción de cada sección.\nLas páginas del manual que describen los comandos accesibles públicamente se encuentran en esta sección. La mayoría de la documentación de los programas que un usuario necesitará se encuentra aquí.\nEsta sección describe todas las llamadas al sistema (requisiciones hacia el kernel de Linux para realizar ciertas operaciones).\nLa sección 3 describe programas rutinas de librería que no son llamdas directas al servicios del kernel. Esta sección y la 2 son de interés casi solamente para programadores.\nEsta sección describe los archivos especiales, funciones relacionadas con los manejadores y el soporte para la red que estén disponibles en el sistema. Típicamente, esto incluye los archivos de dispositivo que se encuentran en /dev y la interfaz del kernel para el soporte de protocolos de red.\nAquí se encuentran los formatos para muchos de los archivos cuyo formato no sea intuitivo. Ésto incluye varios archivos include, archivos de salida de programas, y archivos de sistema.\nEsta sección documenta los juegos,demos y programas triviales. Muchas personas tienen una opinión muy diferente de que tan escencial es esta sección.\nLas páginas del manual que son difíciles de clasificar se designan como pertenecientes a la sección 7. Las de troff y otros macro paquetes de procesamiento de texto se encuentran aquí.\nAquí se documentan los programas utilizados por los administradores de sistemas para la operación y mantenimiento. Algunos de estos programas son ocasionalmente útiles para usuarios normales.\nÉste es utilizado para documentar el código fuente del kernel en los Sistemas Linux.\nEste directorio contiene cualesquier binario no-esencial utilizando exclusivamente por el administrador del sistema.\nLos programas de administración del sistema que sean requeridos para la reparación del sistema, recuperación del sistema, montaje de /usr u otras funciones esenciales deben localizarse en /sbin en vez de aquí.\nTípicamente /usr/sbin contiene los deamons de red, cualquier herramienta de administración no-escencial y binarios para programas servidores no-críticos. Ésto incluye los deamons de internet que son llamados por inted (llamados in.*) tales como in.telnetd y in.fingerd y los deamons basados en rpc manejados por portmap (llamados rcp.*) tales como rcp.infsd y rcp.mountd.\nEstos programas servidores son utilizados cuando se entra en un estado que el System V conoce como "run level 2" (estado multi-usuario) y el "run level 3" (estado en-red) o el estado que el BSD conoce como "modo multi-usuario". En este punto se hacen disponibles los servicios para los usuarios (p. ej. soporte de impresión) y hacia otras máquinas (p. ej. exportar NFS).\nLos programas administrativos instalados localmente deben estar localizados en : /usr/local/sbin.\n6.10 /usr/share : Información Independiente de Arquitectura.\nCualquier especificación para /usr/share se incluirá en un documento suplementario al FSSTND. Note que es la opinión en consenso del FSSTND que /usr/share no es necesario en la mayoría de los sistemas Linux. En este momento, si nos confinamos a proporcionar una definición extensiva de este directorio, sería una mala idea. Por favor refiérase a la sección 6 para una discusión más de /usr/share.\n/usr/src --- Código fuente\nlinux            Código fuente para el kernel de Linux.\nCualquier código fuente no-local debe localizarse en este directorio. El único código fuente que siempre debe localizarse en un lugar específico es el código del kernel (cuando exista o esté enlazado como parte de una estructura en /usr/include). Se pueden usar subdirectorios si se desea.\nEl código fuente para el kernel debe siempre estar en su lugar o al menos los archivos include del código del kernel. Esos archivos están localizados en estos directorios.\nusr/include debe contener enlaces a estos directorios, llamados asm y /Linux, dados que son necesitados por el compilador de C, al menos /estos archivos include deben siempre ser distribuidos en las instalaciones /que incluye un compilador C. Deben ser distribuidos en el directorio //usr/src/linux de forma que no existan problemas cuando los administradores /del sistema actualicen su versión del kernel por primera vez.\n/usr/src/linux puede también ser un enlace simbólico a un árbol de código /fuente del kernel.\n/var    Información variable\nadm             Info administrativa del sistema (obsoleto). Enlace simbólico hacia /var/log\ncatman          Páginas del manual formateadas localmente\nlib             Información del estado de aplicaciones\nlocal           Información variable del software de /usr/local\nlog             Archivos de bitácora\nnamed           Archivos DNS, sólo red\npreserve        Archivos almacenados después de una falla de ex ó vi\nrun             Archivos relevantes a procesos ejecutándose\nspool           Directorios de trabajos en fila para realizarse después\ntmp             Archivos temporales, utilizado para mantener /tmp pequeño\nvar contiene archivos con información variable. Ésto incluye archivos y /directorios en fila de ejecución, información de bitácora administrativa y /archivos temporales y transitorios.\nAlgunas porciones de /var son no-compartibles entre diferentes sistemas. Por ejemplo, /var/log, /var/lock y /var/run. Otras porciones son compartibles, notablemente /var/spool/mail y /var/spool/news.\nvar se especifica aquí para hacer posible el montar /usr sólo-lectura. /Todo aquello que alguna vez fué en /usr que es escrito durante la operación /normal del sistema (pero no durante la instalación y el mantenimiento del /software) debe ir en /var.\nSi /var no puede ser una participación separada, es preferible mover /var fuera de la participación raíz pero dentro de la partición /usr (esto se hace algunas veces para reducir el tamaño de la partición raíz o cuando hay poco espacio en la partición raíz). Como sea, /var no debe ser enlazada a /usr, porque hace que la separación entre /usr y /var sea más difícil y seguramente creará un conflicto de nombres, En vez enlace /var a / usr/var.\nEste directorio ha sido remplazado por /var/log y otros directorios. Debe ser un enlace simbólico a /var/log hasta que todos los programas ya no se refieran más a algún archivo en /var/adm.\nutmp se ha movido a /var/run. Todos los archivos bitácoras se han movido a /var/log incluyen en el archivo wtmp.\nEl soporte de empaquetado de distribuciones se debe almacenar en /var/lib/<nombre> .\nNota: El enlace simbólico /var/adm no debe ser necesario en la mayoría de los sistemas Linux-i386ELF dado que el cambio fué introducido antes que ELF fuera liberado al público.\n7.2 /var/catman : Páginas del Manual Formateadas localmente (opcional)\nEste directorio proporcionara una localización estándar para los sites que proporcionan una partición /usr sólo-lectura, pero que desean permitir el almacenamiento temporal de páginas del manual formateados localmente. Los sites que montan /usr como escribible (p. pj. instalaciones mono-usuarios) pueden escoger no usar /var/catman y escribir las páginas del manual formateadas dentro de los directorios cat[1-9] dentro de /usr directamente. Recomendamos que la mayoría de los sites utilicen una de las siguientes opciones en su lugar.\nPreformateé todas las páginas del manual dentro de /usr con el programa (catman).\n: No se permita el almacenamiento temporal de las páginas formateadas del manual y requiera que se ejecute nroff cada vez que se necesite una página.\nSe permita el almacenamiento temporal local de las páginas del manual en /var/catman.\nLa estructura de /var/catman necesita reflejar ambos, el hecho de la existencia de múltiples jerarquías de página del manual y la posibilidad del uso de múltiples idiomas.\nDada una página del manual sin formatear que normalmente aparece en /usr/<ruta1>/man/man[1-9], la versión formateada almacenada temporal debe ir en /var/catman/<ruta2>/cat[1-9], donde <ruta2> es <ruta1>. Los componentes <ruta2> y <ruta1> están ausentes en el caso de /usr/man y /var/catman.\nPor ejemplo, /usr/man/man1/ls.1 se formatea en /var/catman/cat1/ls.1 y /usr/X11R6/man/<locale>/man3/XtClass.3x lo hace en /var/catman/X11R6/<locale>/cat3/XtClass.3x .\nLas páginas del manual escritas en /var/catman/cat[1-9] pueden eventualmente, transferirse a /usr/<ruta>/cat[1-9] ó expirarse. De igual forma las páginas del manual formateadas dentro de /usr/<ruta>/cat[1-9] pueden expirarse si no son accesadas en un periodo de tiempo.\nSi vienen páginas del manual preformateadas con un sistema Linux en un medio sólo-lectura. (p. ej. un COROM), deben estar instaladas en /usr/<ruta>/cat[1-9]. /var/catman está reservado como un lugar de almacenamiento temporal para páginas de manual formateados.\n7.3 /var/lib : Información de Estado de Aplicaciones.\n/var/lib.- Información de Estado de Aplicaciones\ngames           Información variable de juegos(archivos de marcadores)\ntexmf           Información variable asociada con TeX\nxdm             Archivos de autenticación y bitácoras de error del manejador de despliegues X\nvar/lib/<nombre> es el lugar apropiado para el soporte de /empaquetamiento de todas las distribuciones. Diferentes distribuciones de /Linux pueden utilizar diferentes nombres por supuesto.\nEl directorio del estado GNU Emacs, el lugar donde los archivos de información independiente de la arquitectura, que Emacs modifica cuando se ejecuta, debe ser /var/lib. En el presente, Emacs sólo localiza su directorio de archivos de bloqueo bajo el directorio de estado (en <direstado>/emacs/lock), pero puede hacer uso más extenso del mismo en el futuro. Notablemente, sólo se requiere la adición de una opción sencilla en el programa configure de Emacs para hacer este cambio (antes de compilar).\nAsí como los subdirectorios antes citados, cualquier información variable relacionada con los juegos que se encuentran en /usr/games, deben estar aquí. /var/lib/games debe incluir la información variable que previamente se encontraba en /usr/lib/games; La información estática, tal como textos de ayuda, descripciones del nivel y demás, debe permanecer en /usr/lib/games.\nvar/lib/news se debe usar parea almacenar toda la información variable /asociada con los servidores de news tales como Cnews y INN, inclusive el /archivo histórico, el archivo activo y demás.\nvar/lib/texmf se debe usar para almacenar la información variable /asociada con TeX. Particularmente, en /var/lib/texmf/fonts se /almacenarán todas las fuentes tipográficas que son generadas /automáticamente por MakeTeXPK.\nDebe haber un enlace desde /usr/lib/texmf/fonts/tmp hacia /usr/lib/texmf/fonts. Este enlace permite a los usuarios hacer uso de una sola ruta /usr/lib/texmf/fonts/tfm cuando le hacen cambios a su variable de entorno TEXFONTS (ésta es la ruta por defecto en las herramientas TeX de Karl Berry distribuidas desde ftp.cs.umb.edu:pub/tex [La razón de mencionarlos aquí es que son el estándar de facto en las instalaciones UNIX, estas herramientas son ampliamente usadas entre la comunidad Linux]. Si se utiliza otra distribución de TeX, se debe hacer un enlace desde el directorio de fuentes apropiado hacia /usr/lib/texmf/fonts).\nEl MakeTeXPK que se distribuye con dvipsk colocará los archivos .pk en fonts/pk/<dispositivo>/<nombre_de_la_fuente>, (p.ej. fonts/pk/Canon_CX/cmr10.300pk). Los archivos .pk se pueden purgar periódicamente del árbol /var/lib/texmf o se puede mover dentro del árbol /usr/lib/texmf. Si se usan generadores automáticos de .mf ó .tfm, éstos deben poner su información en los subdirectorios mf ó tfm de /var/lib/texmf/fonts.\n/var/lib/xdm contiene la información variable de xdm que consiste en los /archivos xdm-errors y cualquier archivo de autoridad xdm. Los binarios de /xdm tales como chooser deben aún estar localizados en la localidad /histórica en /usr/X11R6/lib/X11/xdm. El archivo xdm-pid debe estar en //var/lib/xdm a pesar de existir /var/run. Los archivos restantes deben /estar en /etc/X11/xdm.\nEste directorio contiene toda la información variable que esté relacionada con el software que se encuentra en /usr/local. Naturalmente la implementación de este subdirectorio se deja a el administrador del sistema . Como sea la información que se puede categotizar en otro lugar del directorio /var, no se debe colocar en /var/local. Por ejemplo, todos los archivos de bloqueo aún irán en /var/lock.\n7.5 /var/lock : Archivos de Bloqueo\nLos archivos de bloqueo deben almacenarse dentro de una estructura del directorio de /var/lock.\nPara preservar la habilidad de montar /usr sólo-lectura, no se deberá colocar los archivos de bloqueo en la partición /usr.\nLos archivos de bloqueo de dispositivo, tales como los archivos de bloqueo de dispositivos serie que antes se encontraban en /usr/spool/lock ó en /usr/spool/uucp deben ahora almacenarse en /var/lock. la convención para la nomenclatura que debe utilizarse es LCK... seguido del nombre base del dispositivo. Por ejemplo, para bloquear /dev/cua0 se deberá crear el archivo LCK... cua0.\nEl formato usado para los archivos de bloqueo de dispositivo en Linux deberá ser el formato de archivos de bloqueo HDB UUCP. El formato HDB es almacenar el PID (Identificador del proceso) como un número decimal en ASCII de 10 bytes, con un caracter de línea nueva.\nPor ejemplo, si el proceso 1230 retiene un archivo de bloqueo, contendrá los siguientes once (11) caracteres: espacio, espacio, espacio, espacio, espacio, espacio, uno, dos, tres, cero y nueva línea.\nEntonces cualquier cosa que desee usar /dev/cua0, puede leer el archivo de bloqueo y actuar de acuerdo (Todos los archivos de bloqueo en /var/lock deben ser leíbles por todos).\n7.6 /var/log : Archivos bitácora y directorios\nEste directorio contiene archivos bitácora misceláneos. la mayoría de los archivos bitácora se deben escribir en este directorio o subdirectorios apropiados.\nlastlog         Registro del último acceso de cada usuario\nSe puede requerir de un enlace simbólico desde /var/log/utmp hacia /var/run/utmp hasta que ningún programa se refiera a /var/adm/utmp (/var/adm es en sí mismo un enlace simbólico transicional hacia /var/log).\nEste directorio contiene todos los archivos de trabajo del servidor de nombres Internet, named.\n: Recomendamos que /etc/named.boot sea un enlace simbólico hacia /var/named/named.boot, dado que /etc/named.boot es el archivo de arranque por defecto, si no se dan argumentos a named.\n7.8 /var/nis : Archivos de bases de datos del servicio de información dered (NIS)\nEl sistema de información de red (NIS) era anteriormente conocido como las Páginas Amarillas Sun (YP). La funcionalidad y localización de directorios de ambos es el mismo pero el nombre (Yellow Pages) es una marca registrada en el Reino Unido, pertenece a Bristish Telecommunications PLC. y no puede ser usada sin permiso.\nEste directorio contiene los archivos que son almacenados ante cualquier terminación no-esperada de ex, vi, ó de alguno de sus clones.\nEste directorio contiene archivos con información del sistema que lo describen desde que arrancó. Generalmente los archivos en este directorio se deben limpiar (remover o truncar, según corresponda) al comenzar el proceso de arranque.\nLos archivos identificados de proceso (PID), que estaban originalmente /etc, se deben colocar en /var/run. La convención de nomenclatura de archivos PID es <nombre-programa>.pid, por ejemplo el archivo PID de crond se llama /var/run/crond.pid.\nEl formato interno de los archivos PID permanecen sin cambio. El archivo debe de consistir del indicador del proceso en decimales codificado como ASCII, seguido por un caracter nueva línea Por ejemplo, si crond fue el proceso número 25, /var/run/cond.pid contendrá 3 caracteres, dos cinco y nueva línea.\nLos programas que léan archivos PID deben ser flexibles en lo que aceptan, p. ej. deben ignorar los espacios extras, ceros a la izquierda, ausencia del caracter nueva línea o líneas adicionales en el archivo PID. Los programas que crean archivos PID deben utilizar la sencilla especificación dada en el anterior párrafo.\nEl archivo utmp, que almacena información acerca de quién está actualmente utilizando el sistema, se localiza en este subdirectorio.\nLos programas que mantengan sockets transitorios de dominio UNIX, deben colocarlos en este directorio.\nvar/spool es tradicionalmente utilizado para la información local de /máquina que es enviada para procesarse después, hacia o desde subsistemas /UNIX. Por ejemplo, trabajos de impresión que son almacenados aquí para /entrega posterior al daemon de la impresora, el correo que sale es /almacenado aquí para entrega a sistemas remotos y los archivos UUCP son /almacenados aquí para transmisión a los sistemas UUCP vecinos. El correo /que entra y las noticias son almacenados aquí para entregarse a los /usuarios y los trabajos de at y cron son almacenados aquí para ejecución /retardada por el daemon cron.\nmail            Archivos caja-postal(buzón) de los usuarios\nLos archivos de bloqueo UUCP deben localizarse en /var/lock. Véa la sección acerca de /var/lock.\n/var/spool/lpd --- Directorio de fila  de trabajos para proceso posterior o impresión\n<impresora>               Directorio que tiene la fila específica de esta impresora\nEl archivo de bloqueo para lpd, lpd.lock debe estar localizado en /var/spool/lpd. El archivo de bloqueo de cada impresora debe localizarse en el directorio <impresora> de la impresora especifica y se debe llamar lock.\n7.12 /var/tmp : Archivos temporales, utilizando para mantener /tmp pequeño.\nLos archivos que están en /var/tmp están almacenados por una duración no especifica. (Recuerde que los directorios temporales del sistema no garantizan mantener la información por ningún periodo particular).\nLa información almacenada en /var/tmp típicamente se limpia en una "forma definida localmente" pero usualmente menos frecuentemente que /tmp. Se puede encontrar información sobre directorios temporales en la selección dedicada a /tmp (arriba).\nDebe existir un enlace simbólico desde /usr/tmp hacia var/tmp por razones de compatibilidad.\n8. Razonamientos adicionales y asuntos sin resolver\nEsta sección discute varias áreas que pueden requerir mayor explicación.\nLa respuesta es: esencial para limpiar, crear, preparar, verificar, encontrar y montar otros sistemas de archivos (posiblemente en máquinas remotas). Hay otras definiciones, pero ésta es una definición general que la mayoría de las personas al menos la incorporará en la suya.\nLa red presenta un dilema interesante, algunas personas quieren separar los binarios y de configuración de la red de los que no lo son. Como sea, estamos en desacuerdo. Sentimos que la red no es un "paquete", sino una parte integral de la mayoría de la máquinas UNIX (y similares). Debido a lo anterior, la red no debe colocarse en un sólo directorio sino localizarse sistemáticamente en los directorios apropiados.\nAunque puede parecer confuso al principio (y toma tiempo digerirlo), tiene sentido. Si por alguna razón usted sólo puede montar la partición raíz, y necesita accesar a la red para reparar su sistema, no se quiere que los archivos estén en /usr/etc (como están algunas veces). Los archivos que se necesitan para montar /usr en las situaciones normales (y de emergencia) están colocados dentro del sub-árbol raíz, y cualesquier otros se colocan en /usr, para mantener el tamaño del sistema de archivos raíz pequeño.\nLos archivos de configuración para la red pertenecen a /etc.\nEl directorio /usr/share típicamente contiene archivos independientes de la arquitectura, tales como páginas del manual, zona horaria, información de terminfo, etc. En el momento presente no hay diferentes arquitecturas para Linux, pero con el tiempo, veremos que Linux incluirá otras arquitecturas y otros sistemas similares a UNIX.\nNota: Ningún programa nunca deberá hacer referencia a alguna cosa en /usr/share. Por ejemplo, un programa de páginas del manual no debe nunca buscar directamente /usr/share/man/man1/1s.1, sino que siempre se debe referir a /usr/man/man1/1s.1. Cualquier cosa en /usr/share, será "apuntada" a través de uso de enlaces símbolos desde otras áreas del sistema de archivos, tales como /usr/man, /usr/lib/<algo>, etc... Aún se trabaja en las especificaciones de /usr/share.\nHay muchos usos para los enlaces simbólicos en cada sistemas de archivos. Aunque un estándar como éste no respalda el uso de enlaces simbólicos en la implementación por defecto (Los encontrados después de instalar Linux), se usan frecuentemente con buenos propósitos en diferentes sistemas. El punto es que los enlaces simbólicos deben estar allí para mantener todos los archivos y directorios donde cada quien los espera encontrar.\nEstá preparado para aceptar que ciertos directorios, aún aquellos contenidos en el directorio raíz, aún sean enlaces simbólicos. Por ejemplo en algunos sistemas /home no estará en el raíz, sino enlazado simbólicamente a un directorio /var o algún otro lugar. /home podría tener también su propia partición física y desde luego, ser montado como tal.\nSimilarmente, dado que /usr podría estar en un servidor de archivos central montado vía NFS, /usr/local se puede enlazar simbólicamente a /var/local. Este cambio se puede justificar recordando la razón principal de tener /var: separar directorios de archivos que varían con el tiempo y entre diferentes sistemas y máquinas de aquellos que se pueden compartir y sean sólo-lectura.\nAlgunos sistemas además enlazarán /tmp a /var/<algo> si la partición raíz se vuelve muy pequeña (ó es muy pequeña). Hay más ejemplos de "buenos" usos de enlaces simbólicos, pero todo el asunto se reduce a dos cosas: Los paquetes deben ser capaces de encontrar las cosas donde lo esperan (razonablemente) y los enlaces simbólicos se pueden utilizar para resolver los problemas de muchos casos. Como sea, se pueden generar problemas con el uso de demasiados enlaces simbólicos. este problema incluye sobre-confianza en los enlaces simbólicos para resolver problemas, confusión resultante del sobre-uso de enlaces simbólicos y las preferencias estéticas de diferentes personas.\n8.5 Binarios Compilados Estáticamente.\nLinux se ejecuta corre actualmente en una gama de sistemas, algunos con sólo un usuario y disco pequeño, otros como servidores en ambientes con redes muy grandes, dada esta variedad, este estándar no impone regla sobre qué binarios están compilados estáticamente o dinámicamente, con las siguientes excepciones. Ambos ln y sync, deben existir en /bin; cualquier versión estática se puede colocar en /sbin o remplazar aquellas en /bin.\nLos grandes sistemas Linux pueden desear incluir otros binarios estáticos (sh, init, mkfs, fsch, tunefs, mount, umount, swapon, swopff, getty, login y otros). Los desarrolladores y los administradores de sistemas, son libres de enlazar dinámica o estáticamente éstos y otros binarios según le convengan, siempre que la localización de los binarios no cambie.\nEn sistemas de red, (especialmente aquellos que no tienen unidades de disco flexible), pueden querer compilar estáticamente ifconfig, route, hostname y otras herramientas de red. Ésto usualmente no es necesario.\nLa lista del correo del FSSTND se encuentra en <Linux-fsstnd@ucsd.edu>. Esta lista estaba originalmente localizada en <Linux-activists@niksula.hut.fi> "Mail Net" como el canal FSSTND. (Para subscribirse a la lista mande correo <listserv@ucsd.edu> con el mensaje "ADD Linux-fsstnd").\nGracias a Operaciones de Red en la Universidad de California en San Diego quien nos permitió utilizar su excelente servidor de listas de correo.\nSe debe dar crédito por este texto a las activistas FSSTND, desarrolladores, administradores de sistemas y usuarios cuyos comentarios fueron esenciales a este estándar. También deseo agradecer a cada contribuyente que ayudó a escribir, compilar y componer éste, un estándar de consenso.\nDeseo también dar real crédito a aquellos desarrolladores que han visto que el dar a Linux un arreglo común del sistema de archivos es algo que expandirá el desarrollo del sistema operativo Linux. Deseo también la valentía y perseverancia de aquellos desarrolladores de Linux quienes comenzaron a seguir este estándar aún antes de que fuera completado.\nLos que contribuyeron originalmente:\nTheodore Tsó     (US)    tytso@athena.mit.edu


Agencias matrimoniales con extranjeros en barranquilla / Mujer busca hombre para vivir en el campo\n. alquiler de vestidos matrimoniales. 4.1.5. al sur con Perú y Ecuador y al noroeste con Panamá, en. colombiana de hoteles en Barranquilla,.\nAgencias Matrimoniales en Atlántico Barranquilla Colombia, conoce hombres y mujeres que desean una relación seria de matrimonio y están buscando pareja estable.En Medellín hay más de diez agencias matrimoniales. en Colombia en: Cartagena con ocho años, Barranquilla con cuatro años. a una persona del extranjero,.Conocer mujer en Colombia para matrimonio. Soy alegre cariñosa no me gustan las mentiras Busco alguen con la MADURES suficiente Para una relacion.Todo comenzó con un extranjero que vino de vacaciones a Barranquilla,. Desafortunadamente muchas agencias y servicios de citas en Latinoamérica y en el mundo.\nItalianos en el Caribe colombiano - scribd.com\nagencias de turismo en arequipa — Arequipa Peru AQP Soluciones\nCasarse con extranjeros,. chinos y taiwaneses a través de oscuras agencias matrimoniales regresan. perteneciente a la agencia y en la que convivía con.Agencias Matrimoniales en Bogotá. Encuentre Sucursales, Teléfonos y Direcciones de Agencias Matrimoniales en Páginas Amarillas.Issuu is a digital publishing platform that makes it simple to publish magazines, catalogs, newspapers, books, and more online. Easily share your publications and get.\nAgencias matrimoniales online y citas atrevidas\nLegalización de documentos extranjeros en el no se encuentren documentos. jpg, directamente con. Agencias matrimoniales de barranquilla, la pareja ideal.con los periódicos “El Universal” y el “Heraldo” de Barranquilla en una columna fija con el. extranjero en Francia. La. matrimoniales prohibidas. b.. afirmaban que el rol de los capitales extranjeros (en el. de alianzas matrimoniales,. en el comercio de Barranquilla desde 1903 con la compra y.\nCasarse con extranjeros,. chinos y taiwaneses a través de oscuras agencias matrimoniales. "Mi esposo salía para ir al trabajo y yo me quedaba en casa con.Colombiancharm.com es sitio web de citas y contactos por internet con la mision. Unicis, líder en agencias matrimoniales. En Barranquilla. Tenemos 54 miembros femeninos disponibles en menos 8 kilometros. desde donde estás. Vas a poder follar con ellas; Lee las reglas antes de continuar.\nBusca novia de 8 años y buscar amigas barranquilla\nAgencias Matrimoniales en LatinoAmerica. Encuentre en Páginas Amarillas Sucursales, Teléfonos y Direcciones en LatinoAmerica. No somos una pagina de chat o una aplicación para concretar citas con extranjeros. Puedo estar en otra agencias matrimoniales o. solteras.barranquilla@. Toures matrimoniales a Odessa,. Si usted esta verdaderamente interesado en cocnocer cientos de hermosas y sinceras mujeres con el fin de encontrar a alguien.Toures matrimoniales a. por mucho extranjeros. por. se han vinculado a nuestro servicio en Volgograd con la esperanza de encontrar a alguien.\n. afirmaban que el rol de los capitales extranjeros (en. de alianzas matrimoniales como el. en Barranquilla estuvieron entretejidas con otros.\nEl éxito alcanzado por la marca con presencia en 53. Barranquilla, alcanzó en el. Las tendencias en dormitorios matrimoniales para 2014 se diferencian. agencias matrimoniales opiniones; citas con. en barranquilla; judios solteros en. estilo parisino manifieste chat en linea gratis extranjeros. Nuestros servicios son gratis para las mujeres con una. una de las ma's destacadas agencias matrimoniales rusas en Europa que esta' especializada en.\nAgencias de Viajes en Bogotá,. Agencias de Viajes en Barranquilla; Agencias de Viajes en Villavicencio;. Planes al Eje Cafetero con Todo Incluido.\nEs un extranjero llegando a un país. Loc. Off En la pujante ciudad de Barranquilla nace una nueva. Este contenido lo construirá la agencia con insumos.\nToures matrimoniales a Volgograd - spain.loveme.com\nDiseño de Paginas web de Agencias de Matrimonio en. Paginas Web Barranquilla,. de casarse con esa persona. Las agencias matrimoniales suelen tener.www.mycolombianwife. Por favor escriba su usario y contrasena con los que se ha regsitrado anteriormente. Si usted se ha registrado con facebook hagal click en el.Somos una Agencia de Publicidad BTL especializada en la organización de. Estas son algunas de las secciones relacionadas con Modelos en. Barranquilla; Cali.\n. encontrar algo interesante loc verb locución verbal:. Agencias Matrimoniales,. en España o en el extranjero con viajes organizados.. su calidad de vida con un extranjero,. a la eficacia de las agencias matrimoniales que funcionan en. ahora viven en Barranquilla con la ayuda.. hablarás con tu traductora en privado para. con extranjeros que nunca vienen. Con nosotros estás. serios que tienen fines matrimoniales.Es difícil conseguir una información veraz acerca de las agencias matrimoniales Latinas en. lo “último en contactos con. Barranquilla and.Diseño de Paginas web de Agencias de Matrimonio en. de casarse con esa persona. Las agencias matrimoniales suelen tener. net - Barranquilla.Mujeres solteras en Wuopo es gratis. etc etc. no estoy aquí simplemente para chatear,no me gusta perder el tiempo con personas indecis.


La cifra de infectados en la provincia de Córdoba supera ya los 3.000\ncórdobahoy 18:20 01/09/20\nCon los últimos 89 casos positivos desde ayer los test PCR positivos son ya 3.040 con un nuevo rebrote en Luque\nLa Consejería de Salud y Familias de la Junta de Andalucía ha informado, a través de su habitual parte oficial diario, de que, actualmente, 493 pacientes confirmados con Covid-19 permanecen ingresados en los hospitales andaluces, de los que 72 se encuentran en una unidad de cuidados intensivos (UCI).\nPor provincias, en Almería (110 hospitalizaciones, de las que 21 son en UCI); en Cádiz (64 hospitalizaciones, de las que 12 son en UCI); EN Córdoba (49 hospitalizaciones, de los que tres son en UCI); en Granada (48 hospitalizaciones, de las que cuatro son en UCI); en Huelva (cuatro hospitalizaciones convencionales); en Jaén (22 hospitalizaciones, de las que cuatro son en UCI); en Málaga (151 hospitalizaciones, de las que 19 son en UCI), y en Sevilla (45 hospitalizaciones, de las que nueve son en UCI).\nEn la provincia de Córdoba, los datos oficiales de la Junta indican que ya se han sobrepasado con creces los 3.000 infectados. En concreto son en las últimas 24 horas 89 nuevos contagios, con lo que el acumulado llega ya a los 3.040 test positivos.\nSe han producido, además, nueves nuevas hospitalizaciones de ayer a hoy, con un acumulado desde el inicio de la pandemia de 635, de los que 92 han pasado por la UCI, incluidos los dos nuevos ingresos desde ayer.\nLa cifra de fallecidos permanece en 121, y la personas curadas llega ya a las 1.826, con los siete nuevas sanaciones registrados desde el lunes.\nEn materia de rebrotes, la Junta ha registrado el originado en la Residencia de Luque, 18 casos positivos entre sus residentes.\nUn total de 18 de los 24 ancianos de la Residencia de Luque dan positivo en los test PCR de Covid-19\nLas matriculaciones de vehículos eléctricos suben en Córdoba un 100%


9.1 de media en 12 reseñas. 40 habitaciones.\nReserva a partir de $838\nLa Réserve Paris Hotel & Spa se encuentra en París, a 1,1 km del Museo de l'Orangerie, y ofrece bar, spa, centro de bienestar y vistas a la ciudad. El establecimiento cuenta con restaurante, recepción 24 horas, servicio de habitaciones y WiFi gratuita en todas las instalaciones. El hotel cuenta con piscina cubierta, hammam y servicio de conserjería.\nLa Réserve Paris Hotel & Spa ofrece un desayuno continental o a la carta.\nEntre los lugares de interés cercanos al La Réserve Paris Hotel & Spa se incluyen el Jardín de las Tullerías, el Arco del Triunfo y el Museo de Orsay. El aeropuerto más cercano es el de París-Orly, ubicado a 18 km del hotel.\nEncuentra una habitación en La Réserve Paris Hotel & Spa »\nUna guía para encontrar alojamientos fantásticos cerca de La Réserve Paris Hotel & Spa


Asoma otra crisis en Cofepris: rezaga 2 mil permisos de plaguicidas - SonoraPresente\nAsoma otra crisis en Cofepris: rezaga 2 mil permisos de plaguicidas\nLa Comisión Federal para la Protección contra Riesgos Sanitarios (Cofepris) tiene más de 2 mil 11 trámites rezagados en materia de plaguicidas o nutrientes vegetales desde 2018, denuncian organizaciones de la sociedad civil.\nEsto, debido a que el proceso burocrático se ha ralentizado desde inicios de sexenio ya que el organismo ha tenido cambios de administración interna lo que también ha dificultado la resolución de los trámites.\nOtra de las razones por las cuales se han detenido las gestiones entre la Cofepris y los particulares que buscan que se aprueben sus productos, es el fin de la comunicación entre la comisión y los particulares con el argumento del combate a la corrupción que el gobierno federal ha anunciado desde el inicio del sexenio.\n“Se suspendió toda comunicación y esto ha llevado a serios retrasos en las gestiones que hace la industria para efecto de resolver dudas, de llegar a acuerdos con la autoridad que faciliten los procesos internos de la Cofepris que así se hacía anteriormente desde 2018 este diálogo se suspendió por completo”, explica Cristian García de Paz, director ejecutivo de Protección de Cultivos, Ciencia y Tecnología (PROCCYT).\nLa cifra, 2 mil 11, sólo corresponde a los trámites rezagados en el área de plaguicidas y nutrientes vegetales, a los que habría que sumar los trámites de otros ramos como alimentos, bebidas o tabaco.\n“Es la primera ocasión en la que se presentan estos rezagos tan importantes y normalmente era un proceso habitual administrativo donde la Cofepris, si no hacía resoluciones de un día para otro, eran resoluciones que cumplían los tiempos establecidos”, explica García.\nEl director ejecutivo de PROCCYT explica que hay algunos trámites muy sencillos, como el cambio de razón social, que en otro momento podía tomar una semana, ahora llevan más de dos años sin que se puedan finalizar.\nAdemás, no existe una política de gestión clara y unificada para gestionar los plaguicidas, lo que ha generado que aumente el contrabando y falsificación de productos para el campo lo que representa daños para la salud, el medio ambiente y la productividad agrícola.\nSi bien las legislaciones que regulan a la Cofepris están claramente establecidos y definidos, las leyes están dispersas y son responsabilidad de distintas autoridades lo que también complica el cumplimiento de los marcos jurídicos.\nAsí lo señala la Organización para la Cooperación y el Desarrollo Económico (OCDE) en su informe titulado “Gobernanza Regulatoria en el Sector de Plaguicidas de México”.\n“El marco regulatorio de plaguicidas existente en México es exhaustivo, pero está disperso entre varios instrumentos regulatorios y administrado por varias autoridades”, explica la OCDE y recomienda la creación de una única ley federal que aborde estos aspectos para facilitar los procesos de aprobación de plaguicidas.\nCristian García de la Paz coincide con el diagnóstico del organismo internacional porque, afirma, hay seis leyes relacionadas con la aprobación de plaguicidas y más de 30 normas oficiales a lo que se suman las dificultades de la falta de coordinación entre las distintas autoridades.\n“Precisamente esta dispersión de facultades y dispersión de responsabilidades de diferentes dependencias representa una problemática porque además de que están tan dispersas, no hay una coordinación entre las autoridades”, afirma García.\nAlgunas de las consecuencias que esto puede traer para el país es que la seguridad y la autosuficiencia alimentaria puede estar en riesgo, así como la productividad del campo mexicano.\nAdemás, a nivel internacional lo que permite realizar el comercio exterior de productos agrícolas es el estatus fitosanitario de México que podría estar en riesgo, en caso de que las plagas no se controlaran.\n“Si nosotros perdemos el estatus fitosanitario por un mal manejo de plagas, un mal manejo de hierbas, por un mal manejo de hongos que afecten a los cultivos y a los productos del campo en México, nuestro país perdería ese estatus fitosanitario que tiene reconocido a nivel global y se podría perder la posibilidad de exportar nuestros productos a otros países”, alertó Cristian García.\nUna situación de este tipo afectaría principalmente a los productores de aguacate, maíz y cebada.\nOtro de los problemas que PROCCYT ubica en la política de gestión de plaguicidas, ahora en el aspecto internacional, es el hecho de que, a pesar de los acuerdos y tratados de comercio con Estados Unidos y Canadá, la aprobación de un producto en cualquiera de los otros dos países de Norteamérica no garantiza la aprobación del mismo producto en el país.\nEl argumento, la defensa de la soberanía nacional en materia del registro y aprobación de productos, es válido, opina Cristian García, pero puede generar problemáticas de comercio con los países del tratado comercial.\n“Pudiera tener razón este argumento, sin embargo, el enfoque con el que se toma la vulnerabilidad de la soberanía es un poco equivocado porque no estamos hablando de cederle la facultad de registro a un Estado extranjero, sino de homologar los procedimientos regulatorios para facilitar el flujo comercial”, afirma el director ejecutivo de PROCCYT.\nEstas condiciones que parecen circunstanciales podrían convertirse en una política pública que derive en el establecimiento de barreras arancelarias a los productos que se comercializan entre los países que componen el T-MEC lo que podría derivar en procesos judiciales internacionales.\n“No estamos muy lejos de esos niveles de riesgo porque tenemos decretos famosos como el de glifosato que ya establece políticas públicas que son barreras no arancelarias para el intercambio de algunos productos”, explica el director ejecutivo de PROCCYT.\nDe acuerdo con la Organización de las Naciones Unidas para la Alimentación y la Agricultura (FAO), en caso de que los plaguicidas a nivel mundial fallen, se podría perder el 30 % de los cultivos planetarios.\n“Esto es un promedio de la productividad a nivel global. Sin embargo, en nuestro país, la necesidad del control de plagas, del control de maleza, nos lleva a asumir que ese porcentaje podría ser mayor y llegar al 35% de la pérdida de los cultivos o productividad”, explica García.\nDe acuerdo con PROCCYT en el último año se puede hablar de la pérdida de entre el 5% y el 7 % de los cultivos debido a la falta de plaguicidas.\nOtra de las graves consecuencias que la falta de cumplimiento en los trámites de aprobación de plaguicidas y nutrientes vegetales es el predominio del contrabando y falsificación de estos productos lo que puede afectar a la salud de los productores agrícola, al medio ambiente como los mantos freáticos y a la salud de los consumidores.\nAsí lo alerta el Observatorio Nacional Ciudadano que, además, explica que la prevalencia de plaguicidas ilegales promueve un aumento en la violencia del país.\n“¿Por qué hablar de la venta de plaguicidas ilegales? Por el desarrollo de la violencia que se manifiesta en amenazas, lavado de dinero, contrabando y delitos contra el medio ambiente”, afirmó Francisco Rivas director del ONC.\nAdemás, la Senasica ha revelado que una de cada dos muestras analizadas de productos agrícolas, como frutas o verduras, tienen restos de plaguicidas ilegales.\n“Se están importando plaguicidas de manera ilegal, se están adulterando plaguicidas convirtiéndolos en sustancias peligrosas”, afirmó por su parte Cristian García.\nAdemás, de los problemas de salud que pueden representar, los plaguicidas ilegales son vendidos a bajos precios a los productores agrícolas lo que aparentemente podría aumentar sus ganancias, sin embargo, en los hechos terminan afectando a los cultivos, a la tierra y, por lo tanto, la productividad de los cultivos.\n“La Cofepris no está monitoreando de manera efectiva el tema de los plaguicidas ilegales y esto sí representa un peligro para la salud y el medio ambiente”, cuestiona García.\nAmbas organizaciones, el ONC y PROCCYT, han hecho llamados respetuosos a que las autoridades responsables, principalmente la Cofepris, tomen cartas en el asunto tanto para agilizar los trámites correspondientes y para vigilar el comercio ilegal de plaguicidas y nutrientes vegetales.\nCORRUPCIÓN Y FENTANILO\nEl mes pasado, un operativo de la Secretaría de Marina en la Comisión Federal para la Protección contra Riesgos Sanitarios (Cofepris) se llevó a cabo en sus instalaciones porque se detectó corrupción, ya que se dieron permisos de importación de precursores químicos a discrecionalidad, como en el caso del fentanilo, que enfatizó que debe ser controlado por cuestiones internacionales del crimen organizado, dijo en comparecencia Jorge Alcocer.\nEl 6 de octubre fue nombrado el capitán de navío, Francisco Julián Arce, como titular del Órgano Interno de Control y se ha mencionado, explicó la senadora, que la Dirección Ejecutiva de regulación de estupefacientes, psicotrópicos y sustancias químicas será encabezada por la teniente de fragata química Celeste Ruiz que proviene de la Secretaría de Marina.\nEl periodista Darío Celis, en su columna en El Financiero, advirtió hace unos días que se hace limpia en la Cofepris “ante la creciente corrupción que ahí impera”.\nPublicó que el presidente mandó a su hijo Andrés Manuel López Beltrán a meter orden, lo que significó un manotazo a Hugo López-Gatell, cuya subsecretaría asumió desde agosto pasado el control de ese regulador.\n“Pese a la salida de José Novelo, los vicios y corrupción en la operación día a día de ese importante organismo no cesaron. La llegada de Alejandro Svarch, si bien destrabó procesos no fue al fondo del problema. La mano de ´Andy´ se empezó a sentir hace diez días tras el cese de funcionarios claves. El 30 de septiembre salieron Olga Piña y América Orellana, día que la Marina arribó a custodiar las instalaciones”.