<!-- El maquetador pide disculpas anticipadamente por no haberse puesto en
contacto con los autores antes de pasar el documento a SGML. Como un
servidor no saca nada de ésto, confía en que no halla mayor problema. -->

<!doctype linuxdoc system>
<article>

<!-- Title Info -->
                     
<title>Estructura del Sistema de Archivos de <bf/Linux/
<Author>Grupo de Standard de el Sistema de Archivos &#91;<bf/FSSTND/] &nl; 
Daniel Quinlan &nl;
Traductor: Israel Barrientos <tt><htmlurl url="mailto:jbarrien@ccr.dsi.uanl.mx" name="mailto:jbarrien@ccr.dsi.uanl.mx"></tt>&nl; 
Maquetador Linuxdoc-SGML: Antonio Ismael Olea González, &nl;
<tt><htmlurl url="mailto:olea@poboxes.com" name="mailto:olea@poboxes.com"></tt>
<tt>2:345/108.9@fidonet.org</tt>
<date>r1.2, abril de 1996

<abstract>
El proceso abierto y distribuido en el cual el sistema operativo <bf/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
<bf/Linux/. Este documento intenta especificar la localización estándar de
archivos y directorios en sistemas <bf/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.
</abstract>

<toc>

<sect>Advertencia legal 

<p> <bf/Linux/ no es una Marca Registrada y no tiene conexión con <bf/UNIX/
&nl; <bf/UNIX/ es una marca registrada de <bf/X/Open Company, Ltd/.&nl;
<bf/HP-UX/ es una marca registrada de <bf/Hewlett-Packard/.&nl; <bf/Novell/
y <bf/Novell NetWare/ son marcas registradas de <bf/Novell/. &nl; <bf/SunOS
Sun Microsystems/, <bf/Sun NIS/, <bf/Sun RPC/, y <bf/NFS/ son marcas
registradas de <bf/Sun Microsystems/.&nl; <bf/System V/ y <bf/SVR4/ son
marcas registradas de <bf/AT&amp;T/. &nl; <bf/X Windows System/ es una marca
registrada de el <bf/X Consortium, Inc/.&nl; Todos los otros copyrights son
de los propietarios, a menos que se especifique otra cosa .&nl; El 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.&nl;

<p>
Copyright 1994 Daniel Quinlan

<p> Se permite la distribución y copia de este estándar siempre que se
preserve este copyright y este mensaje en todas las copias.

<p> Se permite a los participantes y contribuyentes de la <bf/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.

<p> Ninguna porción de este documento puede ser redistribuida en una forma
modificada o recortada sin la aprobación previa de el coordinador del
<bf/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 <bf/FSSTND/ para la licencia apropiada. <p>

<sect>Prefacio 
<p>
<sect1>Estatus del Estándar

<p> Ésta es la versión 1.2 de la Estructura del Sistema de Archivos de
<bf/Linux/ (<bf/Linux/ Filesystems Structure) <bf/FSSTND/

<p> Las 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.

<sect>Organización del Estándar
<p>
Este estándar está dividido en 6 partes:
<itemize>

<item>General: incluyendo un enunciado de enfoque, problemas, objetivos, y requerimientos de conformidad. (<ref id="sec1" name="Sección 1">). 
<item>El Sistema de Archivos: Un enunciado de algunos principios guías.  (<ref id="sec2" name="Sección 2">). 
<item>El Directorio raíz <tt>/</tt>:  (<ref id="sec3" name="Sección 3">). 
<item>La jerarquía <tt>/usr</tt>:  (<ref id="sec4" name="Sección 4">). 
<item>La jerarquía <tt>/var</tt>:  (<ref id="sec5" name="Sección 5">). 
<item>Razonamientos adicionales y asuntos sin resolver  (<ref id="sec6" name="Sección 6">). 
</itemize>

<sect1>Convenciones Tipográficas 

<p> La fuente tipo courier se usa para los nombres de archivos y
directorios.

<p> Los componentes de nombres de archivos que varían son representados por
una descripción del contenido encerrada entre los caracteres &dquot; &lt;
&dquot; y &dquot; &gt; &dquot;. Las direcciones de correo electrónico están
también encerradas entre &dquot; &lt; &dquot; y &dquot; &gt; &dquot; pero se
muestran en la fuente usual.

<p> Los componentes adicionales de los nombres de los archivos se encierran
entre los caracteres &dquot; [ &dquot; y &dquot; ] &dquot; y pueden ser
combinados con la convención &dquot; &lt; &dquot; y &dquot; &gt; &dquot;. Por
ejemplo, si existe un archivo que puede ser encontrado con o sin extensión,
éste podría ser representado por &lt;nombre&gt;[.extensión].

<p> Las subcadenas variables de los nombres de archivos y directorios se
indican con &dquot; * &dquot;.

<sect>General <label id="sec1"> 
<sect1>Enfoque

<p> Este documento especifica una estructura estándar del sistema de
archivos para los sistemas <bf/Linux/, incluyendo la localización de
archivos y directorios, y el contenido de algunos archivos de sistema.

<p> El 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
<bf/Linux/ ó jerarquía de directorios.

<p> É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 <bf/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 &dquot;estándares&dquot; (tales como
System V, BSD, SunOS, y otras). El sistema de archivos era poco familiar e
incómodo para los usuarios de <bf/UNIX/ con experiencia y los
administradores que habían tenido experiencia con otros sistemas operativos
similares a <bf/UNIX/.  La falta de regularidad también confundía a los
recién-iniciados en <bf/Linux/, especialmente aquellos que no tenían un
conocimiento previo de <bf/UNIX/. Cualquier incompatibilidad entre las
distribuciones primarias de <bf/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).

<p> En 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
<bf/Linux/ deben opacar estas diferencias.

<p> Este estándar del sistema de archivos fue primeramente desarrollado
dentro de la lista de correo <bf/FSSTND/ y previamente, en el canal
<bf/FSSTND/ de la lista de correo de los LINUX-ACTIVISTS. Los comentarios y
recomendaciones fueron recibidos de un gran numero de desarrolladores de
<bf/Linux/, notables programadores de <bf/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.

<p> Este estándar busca atacar los problemas estos problemas con una
estructura de sistema de archivos bien diseñada que esperamos que la
comunidad <bf/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 <bf/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 <bf/FSSTND/ planea
publicar suplementos y actualizaciones periódicas a este documento.

<p> Los comentarios relacionados con este documento se agradecen y son
bienvenidos por el grupo <bf/FSSTND/. Cualquier comentario o sugerencia de
cambio deberá ser dirigida a al coordinador del <bf/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
<bf/FSSTND/.


<p> Existe 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 <bf/FSSTND/ o si tiene alguna pregunta por favor lea
antes el <bf/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. <p>

Por favor no mande correo a la lista de correo sin antes contactar a el
coordinador del <bf/FSSTND/ o a un colaborador listado. Los mensajes
impropios no van a ser bien recibidos en la lista. <p>

Preguntas 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. <p>

El coordinador del <bf/FSSTND/ es Daniel Quinlan
&lt;Daniel.Quinlan@linux.org&gt; <p>

<sect1>Problemas específicos.

<p> Naturalmente, existían ciertos problemas específicos que tratábamos de
corregir cuando estandarizamos la estructura del sistema de archivos de
<bf/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
<bf/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 <bf/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.

<p> Mientras 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.


<sect1>Objetivos

<p> Al 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.

<p> Resolver 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 <bf/Linux/, así como
alentarlos a que compartan con nosotros sus sugerencias. Proveer un estándar
que la comunidad <bf/Linux/ escoja seguir por que resuelve los problemas
anteriores y provee la más sensata estructura de sistemas de archivos de las
instalaciones <bf/Linux/.

<p> Algunos 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.



<sect1>Historia y Progreso

<p> El mensaje original que motivó este esfuerzo para reestructurar el
sistema de archivos <bf/Linux/ fue escrito por Olaf Kirsh
&lt;okir@monad.swb.de&gt; el 02 de Agosto de 1993 en el entonces canal
NORMAL de la lista de correo de los LINUX-activists.

<p> En corto tiempo se decidió que la mejor manera para acometer la
necesaria reestructuración de el sistema de archivos de <bf/Linux/ sería la
creación de una lista de correo separada con el fin de desarrollar un
standard de consenso.

<p> Despué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 <bf/FSSTND/ para mayor discusión.

<p> El primer borrador fue emitido al canal el 18 de Septiembre de 1993 por
 Daniel Quinlan.

<p> Al tiempo que la discusión continuaba y los borradores de las
recomendaciones de el <bf/FSSTND/ se desarrollaban más, se establecieron
contactos con los desarrolladores más accesibles quienes entonces ofrecieron
su apoyo y comentarios a nuestro esfuerzo.

<p> Muchos desarrolladores de <bf/Linux/ estuvieron de acuerdo en que este
esfuerzo de estandarización valía la pena y lo apoyaron.

<p> A continuación estan algunos de los desarrolladores que intentan seguir
el estándar <bf/FSSTND/, parcial o completamente, listados en orden
alfabético:


<descrip>
<tag/ATIM LINUX/PRO/ 
Fred N van Kempen et al. &lt;waltje@infomagic.com&gt;
<tag/BOGUS LINUX/
Rik Faith, Kevin E. Martin, y Doug L. Hoffman &lt;linux-bogus@cs.unc.edu&gt;
<tag/DEBIAN LINUX/
Ian A. Murdock   &lt;imurdock@debian.org&gt;
<tag/LILO boot loader/
Werner Almesberger  &lt;almesber@nessie.cs.id.ethz.ch&gt;
<tag/MCC Interim LINUX/
Owen LeBlanc	&lt;LeBlanc@mcc.ac.uk&gt;
<tag/Red Hat Software LINUX (RHS LINUX)/
Marc Ewing  &lt;marc@redhat.com&gt;
<tag/Slackware LINUX/
Patrick J. Volkerding  &lt;volkerdi@mhd1.moorehead.msus.edu&gt;
<tag/TAMU LINUX/
Dave Safford  &lt;dave.safford@net.tamu.edu&gt;
<tag/util-linux  (paquete)/
Rik Faith  &lt;faith@cs.unc.edu&gt;
<tag/Yggdrasil Plug-and-Play LINUX/
Adam J. Richter &lt;adam@yggdrasil.com&gt;
</descrip>

<sect1>Conformidad con este Documento

<p> Esta sección define los términos &dquot;conforme&dquot; y
&dquot;compatible&dquot; con respecto a este estándar, y el de &dquot;
&dquot;parcialmente&dquot; conforme y compatible.

<p> Una &dquot;implementación&dquot; 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. <p>

Una 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. <p>

Una 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. <p>

Una 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 <bf/FSSTND/. Se anticipa que cierta variación será tolerada
en casos marginales. <p>

Para calificar como parcialmente conforme con <bf/FSSTND/ o parcialmente
compatible con <bf/FSSTND/, una implementación debe de proporcionar una
lista de lugares en los cuales ella y el <bf/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 <bf/FSSTND/ o el coordinador del <bf/FSSTND/. <p>

Los términos &dquot;tiene que &dquot;, &dquot;debe&dquot;, &dquot;contiene&dquot;,
&dquot;es&dquot; y demás deben ser leídos como requerimientos para la
conformidad o compatibilidad. <p>

Note 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. <p>

Má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 &dquot; puede&dquot;, &dquot;se recomienda&dquot; o &dquot;se
sugiere&dquot; . 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.  <p>

<sect>El sistema de Archivos <label id="sec2">
<p>
El sistema de archivos <bf/UNIX/ está caracterizado por:

<p> Una estructura jerárquica. &nl; Un tratamiento consistente de la
informacion de los archivos. &nl; Proteccion de los archivos.

<p> Este estándar del sistema de archivos <bf/Linux/ sigue el mismo
principio basico que la mayoría de los sistemas de archivos <bf/UNIX/
siguen. Note, sin embargo que este estándar no intenta concordar en cada
aspecto posible con alguna implementacion particular del sistema <bf/UNIX/.
De cualquier forma, muchos de los aspectos de este estándar estan basados en
ideas encontradas en <bf/UNIX/ y sistemas similares a <bf/UNIX/.

<p> Es posible después de cuidadosa consideracion de otros factores,
incluyendo:

<p> Prácticas comunes en la comunidad <bf/Linux/.&nl; La implementación de
otras estructuras de sistemas de archivos.&nl; Los estándares
aplicables.&nl;

<p> Definir dos categorizaciones ortogonales de archivos: Compartibles vs.
no compartibles, y variables vs. estaticos.

<p> La 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.

<p> La 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.

<p> El 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.

<p> La distinción entre información compartible y no compartible es
 necesaria por varias razones:

<p> En 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.&nl; En 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).&nl; Las 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.

<p> La distincion &dquot;compartible&dquot; puede ser usada para soportar, por
ejemplo:

<itemize>
<item>Una partición /usr (o componentes de /usr) montada (sólo-lectura) atraves de la red (usando NFS).
<item>Una particion /usr (o componentes de /usr) montada desde medios de sólo-lectura.Un cd-rom puede ser considerado como un sistema de archivos  sólo-lectura compartido con otros sistemas <bf/Linux/ utilizando el sistema de correo como una red.
</itemize>

La distincion &dquot;estática&dquot; contra &dquot;variable&dquot; afecta el
sistema de archivos de dos maneras principales:

<p> Dado que / contiene ambos tipos de información, variable y estática
necesita montarse lectura-escritura.&nl; Dado 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. <p>

<sect1>Tabla con ejemplos.

<p>
CompartibleNo-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:

<p> Para 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. &nl;
Para 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. &nl; Para 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).

<p> La 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 /

<p> Es frecuentemente montado desde media muy pequena. Por ejemplo muchos
usuarios de <bf/Linux/ instalan y recuperan sistemas montando / como un
disco ram, que es copiado de un disco de 1.44Mb único. &nl; El 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. &nl; Aunque 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. &nl; Los 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. &nl;
En 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.

<p> El software no deberá crear o requerir archivos o subdirectorios
especiales en el directorio /. La estructura del sistema de archivos
<bf/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. <p>

<sect1>El Directorio Raíz <label id="sec3">
<p>
<tscreen><verb>

bin  		Binarios de comandos esenciales  
boot 		Archivos estáticos de cargador de arranque(boot-loader)
dev  		Archivos de dispositivos
etc  		Configuración del sistema local-máquina
home 		Directorios home de los usuarios
lib  		Librerías compartidas
mnt  		Punto de montaje de particiones temporales
root 		Directorio hogar del usuario root
sbin 		Binarios del sistema esenciales
tmp  		Archivos temporales 
usr  		Segunda jerarquía mayor
var 		Información variable
</verb></tscreen>

<p> Cada 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.

<p> El kernel de <bf/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 <bf/Linux/ recientes.
Más información de la localización del kernel se puede encontrar en la
sección acerca de / más delante. <p>

<sect1> /bin	Binarios de comandos esenciales de usuarios (disponibles para todos los usuarios).

<p> bin 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.

<p> Todos 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, &dquot;Razonamientos adicionales y asuntos sin resolver&dquot;.

<p> No habrá subdirectorios dentro de /bin.

<p> Los 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 /.

<p>
Archivos requeridos en /bin:

<sect2>Comandos generales:

<p> Los siguientes comandos han sido incluidos porque son esenciales.
algunos están presentes debido a que tradicionalmente han estado en /bin.
<p>

<tscreen>
<code>
arch, cat, chgrp, chmod, chown, cp, date, dd, df, dmesg, echo, ed, false,kill, in, login, mxdir, mknod, more, mount, mv, ps, pwd, rm, rmdir, sed, setserial, sh, sfty, su, sinc, true, umount, uname.
</code>
</tscreen>

Si /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.

<p> Dado 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).

<p> Los comandos &#91; 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 <bf/Linux/. Estos comandos estarían localizados dentro
de /usr/bin. (se deben incluir como binarios separados con cualquier sistema
<bf/Linux/ que intente cumplir con el estándar POSIX).

<p> bin/arch produciría el mismo resultado que uname-m, especificamente; 386
/o; 486 para sistemas intel y compatibles.

<sect2>Comandos para restauración.

<p> Estos comandos se han incluido para hacer posible el restaurar el
sistema(siempre que / este intacto). &nl;

<tscreen>
<code>
tar, gzip, gunzip (enlace hacia gzip), zcat (enlace hacia gzip).
</code></tscreen>

Si 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 /. &nl; Los
comandos de restauración pueden aparecer en, ya sea /bin ó /usr/bin en
sistemas <bf/Linux/ diferentes. <p>

<sect2>Comandos de red.
<p>
Éstos son unicamente los binarios de red que los usuarios y root querrán o necesitarán ejecutar que no sean los que estan en /usr/bin ó /usr/local/bin &nl; 
<tscreen>
<code>
domainname, hostname, netstat, ping.
</code>
</tscreen>

<sect1>/boot:	Archivos estáticos del cargador de arranque (boot loader).

<p> Este 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.

<p> Como se expuso arriba, el kernel de <bf/Linux/ puede estar localizado en
/ ó en /boot, si se localiza en /boot, recomendamos que se le dé un nombre
más descriptivo.

<sect1> /dev Archivos de dispositivos.

<p> Éste es el directorio de los dispositivos. Contendría un archivo por
cada dispositivo que el kernel de <bf/Linux/ puede soportar.

<p> dev 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.

<p> MAKEDEV 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.

<p> Los enlaces simbólicos no se deben distribuir en sistemas <bf/Linux/,
sino sólo como se preveé en la lista de dispositivos de <bf/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.

<p> Este documento incorpora como referencia la lista de dispositivos de
<bf/Linux/, mantenida por: Peter.Anvin@linux.org: El encargado de los
dispositivos <bf/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. <p>

<sect1>/etc : Configuración del sistema local a la máquina.

<p> etc contiene archivos y directorios que son locales al sistema actual.

<p> Ningú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.

<tscreen><verb>
/etc --- Configuracion de sistemas locales de máquina.

X11 		Archivos deconfiguracion para el x11
skel 		Esqueletos de configuracion de usuarios
</verb></tscreen>

<p> etc/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).

<p> etc/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.

<p> Los 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.

<p> etc/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.

<p> La siguiente sección intenta parcialmente examinar la descripción del
 contenido de /etc con algunos ejemplos: Definitivamente ésta no es una
 lista exhaustiva.

<p>
Archivos requeridos en /etc:

<sect2>Archivos generales:

<p> Estos archivos son necesarios en la mayoría de los sistemas <bf/Linux/.
&nl;

<tscreen>
<code>
adjtime, csh.login, disktab, fdprm, fstab, gettydefs, group, inittab, issue, ld.so.conf, lilo.conf, magic, motd, mtab, mtools, passwd, profile, psdatabase, securetty, shells, syslog.conf, tercamp, ttytype
</code>
</tscreen>

<sect2>Archivos de Red: <p> Estos archivos estarían instalados en la mayoria
de los sistemas <bf/Linux/. &nl; 

<tscreen> <code> 

exports, ftpusers, gateways, hosts, host.conf, host.equiv, host.lpd,
inetd.conf, networks, printcap, protocols, resolv.conf.rpc, services

</code> </tscreen> 

<p> Hay dos modelos para la instalación de los scripts de comandos
&dquot;rc&dquot; 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.

<p> Los 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). <p>

<sect1>/home:  Directorios hogar de los usuarios (opcional) 

<p> home 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
/<bf/Linux/ usen este lugar como la localización por defecto de los
/directorios hogar.

<p> En sistemas pequeños, cada directorio de usuario es uno de los
subdirectorios debajo de /home, p.ej. /home/smith, /home/torvalds,
/home/operador, etc.

<p> En 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.

<p> Muchas 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. <p>

<sect1>/lib: Librerías compartidas y módulos de kernel escenciales

<p> El 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.

<p> lib --- librerías compartidas y modulos de kernel esenciales. &nl;
modules	Modulos de kernel cargables.

<p> Esto 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.

<p> Las 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.

<p> Por 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/&lt;target&gt;/&lt;version&gt;/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).

<p> La especificación para /lib/modules está aún por aparecer. <p>

<sect1>/mnt:  Punto de montaje para sistemas de archivos montados temporalmente.

<p> Este 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.

<p> Recomendamos 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.

<sect1>/proc:  Sistema de archivos virtual de informacion de procesos y del kernel.

<p> El 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. <p>

<sect1>/root:  Directorio hogar de root (opcional)

<p> El directorio / es tradicionalmente el directorio hogar del usuario root
en los sistemas <bf/UNIX/.  /root se usa en muchos sistemas <bf/Linux/ y en
algunos sistemas <bf/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.

<p> Si 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.

<p> NOTA: 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.

<p> <sect1>/sbin: Binarios del Sistema (Alguna vez mantenidos en /etc)

<p> Los ú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.

<p> Decidir 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).

<p> Archivos 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.

<p> Los usuarios ordinarios no tendrán que poner ninguno de los directorios
sbin en su búsqueda (path).

<p> Recomendamos 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.

<p>
Archivos requeridos en /sbin:
<p>
<sect2>Comandos Generales.
<p>
<tscreen>
<code>
clock, getty, init, update, mkswap, swapon, swapoff, telinit.
</code>
</tscreen>
<p>
<sect2>Comandos de Apagado.
<p>
<tscreen>
<code>
fastboot, fasthalt, halt, reboot, shutdown.
</code>
</tscreen>
<p>
<sect2>Comandos de manejo de sistemas de archivos.
<p>
<tscreen>
<code>
fdisk, fsck, fsck.*, mkfs, mkfs.*
</code> 
</tscreen>
<p>
donde * = uno de los siguientes. &nl;
ext, ext2 minix, msdos, xia, y tal vez otros. &nl;

<sect2>Comandos del sistema de archivos ext2 (opcional)
<p>
<tscreen>
<code>
badblocks, dumpe2fs, e2fsck, mke2fs, mklost+found, tune2fs.
</code>
</tscreen>
<p>
Instalador del mapa del cargador de arranque. &nl;
<p>
<tscreen>
<code>
lilo
</code>
</tscreen>

<sect2>Comandos de Red.
<p>
<tscreen>
<code>
arp, ifconfig, route.
</code>
</tscreen>
<p>

Archivos opcionales en /sbin:

<sect2> Binarios estáticos. (compilados estáticamente)

<p> ln 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.

<p> El 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: &nl; Se acaba de remover
/lib/&lt;archivo&gt;. &nl; No 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 &dquot;echo * &dquot; como
remplazo. &nl; Se tiene un sln, pero no se sabe como nombrar al enlace. <p>

<tscreen>
<code>
ldconfig, sln, ssync.
</code>
</tscreen>

<p>
<sect2>Misceláneos
<p>
Para lidiar con el hecho de que muchos teclados vienen con una tasa de repeticion tan alta como para hacerlos inutilizables, se puede instalar kbdrate en /sbin en algunos sistemas.  Dado que la acción por defecto del kernel ante la combinacion de teclas Ctrl-Alt-Del es un rearranque instantáneo duro, es recomendable generalmente deshabilitar esta conducta antes de montar el sistema de archivos raíz con modo lectura-escritura. Algunas suites init son capaces de deshabilitar Ctrl-Alt-Del, pero otras pueden requerir el programa ctrlaltdel, el cual puede ser instalado en /sbin en estos sistemas.
<p>
<code>
ctrlaltdel, kbdrate
</code>
<p>

<sect1>/tmp:  Archivos temporales.

<p> tmp se utiliza para archivos temporales, preferentemente en un
/dispositivo rápido (un sistema de archivos basado en memoria por ejemplo)

<p> La &dquot;persistencia&dquot; 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.

<p> Los 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.

<p> Los 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.

<p> tmp puede estar e un disco RAM.  /var/tmp no debe nunca localizarse en
/algun dispositivo RAM.
<p>

<sect>La jerarquía /usr <label id="sec4">

<p> usr 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 <bf/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.
<p>

Ningun paquete grande (como <bf/TeX/ o <bf/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. <p>

<tscreen><verb>
/usr --- Segundo mayor punto de montaje (permanente)

X11R6		Sistema X Window Version 11 release 6
X386		Sistema X Windows Version 11 release 5 en plataformas  X 86
bin 		La mayoría de los comandos de usuario
dict		Listas de palabras
doc 		Documentación miscelánea
etc		Configuración del Sistema (todo el site)
games		Juegos y binarios educacionales
include		Archivos header incluidos por programas C
info		Directorio primario del sistema GNU Info
lib 		Librerías
local		Jerarquía local (vacía justo después de la instalación principal)
man 		Manuales en línea
sbir		Binarios de Administración del Sistema No-Vitales
share		Información independiente de la arquitectura
src		Código fuente
</verb></tscreen>

Los 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. <p>

<tscreen><verb>

/usr/adm  ------------------&gt;  /var/adm
/usr/preserve  -------------&gt;  /var/preserve
/usr/spool  ----------------&gt;  /var/spool
/usr/tmp  ------------------&gt;  /var/tmp
/var/spool/locks  ----------&gt;  /var/lock

</verb></tscreen>

Una 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. <p>

<sect1>/usr/X11R6:  El sistema X Window, Version 11 release 6

<p> Esta jerarquía está reservada para el sistema X Window, Version 11
release 6 y archivos relacionados.

<tscreen><verb>
/usr/X11R6 --- X Window System (Version 11, release 6)

bin
doc
include
lib
man
</verb></tscreen>

<p> Para simplificar los problemas y hacer <bf/XFree86/ más compatible con
el sistema X Window en otros sistemas, los siguientes enlaces simbolicos
deben estar presentes.

<p>
<tscreen><verb>

/usr/bin/X11  ------------&gt;  /usr/X11R6/bin
/usr/lib/X11  ------------&gt;  /usr/X11R6/lib/X11
/usr/include/X11  --------&gt;  /usr/X11R6/include/X11
</verb></tscreen>

En 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 . &nl; Por la misma razón no debe existir un enlace desde
/usr/X11 apuntando a la jerarquía del sistema X Window actual. <p>

<sect1>/usr/X386:  El sistema X Window, Version 11 release 5 en plataformas X 86

<p> Esta 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
<p>

<sect2>/usr/bin:  La mayoría de los comandos del usuario.
<p>
Éste es el directorio principal de comandos ejecutables en el sistema.
<tscreen><verb>
mh	comandos para el sistema de manejo de correo M H 
X11	Enlace simbólico hacia /usr/X11R6/bin
</verb></tscreen>

Debido a que los interpretadores de scripts de los shell (invocados con #!
&lt;ruta&gt; 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. <p>

<sect1>/usr/dict:  Listas de palabras 
<p>
Archivos recomendados en /usr/dict &nl;
<code>
words
</code>

Tradicionalmente 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.

<p> Las 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)

<p> Cualquier otra lista de palabras, tal como el directorio web2, debe ser
incluido aquí, si está presente.

<p> Las 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. <p>

<sect1>/usr/etc:  Configuración del sistema (todo el site)

<p> Almacenar 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.

<p> Una 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.

<p> Eventualmente 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 <bf/Linux/ lo incorporen. &nl; No 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. <p>

<sect1>/usr/include:  Directorio para archivos include estándar.

<p> Aquí es donde todos los archivos include de uso general del sistema para
programación en lenguajes C y C++ deben ser localizados.

<tscreen><verb>
/usr/include	Archivos include
X11		Enlace simbólico hacia /usr/X11R6/include/X11
arpa 		Definiciones del protocolo definido por  ARPNET.
asm		Enlace simbólico hacia /usr/scr/linux/include/asm-&lt;arch&gt;.
bsd		Archivos include de compatibilidad con BSD.
g++		Archivos include de GNU C++.
gnu		Archivos include GNU.
linux		Enlace simbolico a /usr/src/linux/include/linux.
net		Definiciones genéricas relacionadas con redes.
netax25		Definiciones específicas a  +AX25 ( ARRL AX25).
netinet		Definiciones específicas a  TCP/IP.
netipx 		Definiciones específicas a +IPX (Novel IPX/SPX).
protocols	Definiciones de protocolos ( Mayormente basadas en  INET)
readline	La librería readline GNU.
rpc		Definiciones RPC de Sun Microsystems.
rpcsvc		Definiciones de servicios RPC de Sun Microsystems.
sys		Archivos  include de generación de sistemas.
</verb></tscreen>

<p> El subdirectorio arpa contiene definiciones de cabecera de protocolos
para los protocolos ARPANET, TCP/IP, definiciones para ftp, prototipos
telnet y material similar.

<p> El subdirectorio net contiene definiciones genéricas relacionadas con
redes, define la interface sistema-kernel, detalles de la familia de
protocolo, etc.

<p> El subdirectorio netinet contiene definiciones especificas de INET
(DARPA Internet, que tambien es conocida como TCP/IP )

<p> ARRL AX.25 es mejor conocido como packet radio. Los protocolos novell
IPX/SPX son parte de los servicios de archivos Novell Netware. <p>

<sect1>/usr/lib:  Librerías para programas y paquetes.

<p> usr/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.
<p>

<tscreen><verb>
/usr/lib/ - librerias para programción y paquetes:

X11		Enlace simbólico a /usr/X11R6/lib/X11
emacs		Archivos de soporte estáticos para el editor GNUEmacs.
games		Archivos de datos estáticos para /usr/games.
groff		Librerías / Directorios para GNU groff
gcc-lib		Archivos/ Directorios específicos del sistema para gcc.
kbd		Tablas de traducción de teclado e información relacionada.
Mh		Librerías para el sistema de manejo de correo MH:
news		Cnews/INN.
smail		Smail.
terminfo	Directorios para la base de datos terminfo.
texmf		TeX/MF ( y LaTeX ) librerías de información.
uucp		Comandos de  UUCP.
zoneinfo	Configuración e información de la zona horaria.
</verb></tscreen>

Históricamente, /usr/lib ha incluido además algunos comandos ejecutables
tales como sendmail y makewhatis. &nl; Dado 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 <bf/Linux/, debe también estar en
usr/bin

<p> El 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.

<p> En sistemas que utilizan smail deben localizar smail en /usr/sbin/smail
y /usr/bin/sendmail debe ser un enlace simbolico a smail. &nl; Este arreglo
también se conforma a la nueva locación estándar sendmail definida en
Sendmail 8.6.x y BSD 4.4 &nl; Note que esta localización demanda que
/usr/sbin y /usr/sbin/sendmail deben ser ejecutables para usuarios normales.

<p> Cualquier 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.

<p> La 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.

<p> Nota: 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). <p>

<sect1>/usr/local:  Jerarquía local

<p> La 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.

<tscreen><verb>
/usr/local	Jerarquía local.

bin		Binarios sólo-locales
doc		Documentación local
etc		Binarios de configuración sólo-local
games		Juegos instalados localmente
lib		Librerís para /usr/local
info		Páginas de info local
man		Jerarquías de páginas de manual para /usr/local
sbin		Administración del sistema sólo-local
scr		Código fuente local.
</verb></tscreen>

Este directorio debe estar vacío al terminar de instalar <bf/Linux/ por
primera vez. No debe haber excepciones a la regla, excepto quizá los
subdirectorios vacíos listados.

<p> El 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.

<p> Note 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. <p>

<sect1>/usr/man :  Páginas del manual.

<p> Esta sección detalla la organización de las páginas del manual a través
del sistema. Incluyendo /usr/man.

<p> Las páginas del manual están almacenadas
&lt;mandir&gt;/&lt;locale&gt;/man [1-9]. Más delante se dá una explicación
de &lt;mandir&gt; y &lt;locale&gt;.

<p>
<tscreen><verb>
&lt;mandir&gt;/&lt;locale&gt; --- Una  jerarquía de páginas de manuales.

man1		Programas para usuarios.
man2		Llamadas al sistema.
man3		Subrutinas y funciones de librería
man4		Dispositivos.
man5		Formato de archivos
man6		Juegos.
man7		Misceláneas.
man8		Administración del Sistema.
man9		Funciones y variables internas del kernel.
</verb></tscreen>

El &lt;mandir&gt; 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.

<p> Se 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.

<p> Esta 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 &lt;locale&gt;es: &nl;
&lt;idioma&gt;[&lt;_territorio&gt;][.&lt;conjunto_de_caracteres&gt;][,&lt;version&gt;]

<p> El campo &lt;idioma&gt; 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.

<p> El campo &lt;_territorio&gt; 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.

<p> El campo &lt;conjunto_de_caracteres&gt; debe representar el estándar que
describe el código de caracteres. Si el campo &lt;conjunto_de_caracteres&gt;
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.

<p> Un párametro que especifique &lt;version&gt; del perfil puede ser
colocada despues del campo &lt;conjunto_de_caracteres &gt;, 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 &lt;version&gt; a menos que sea necesario.

<p> En 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
&lt;locale&gt; y almacenar todas las páginas del manual en &lt;mandir&gt;.
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).

<p> En países para los cuales existe un código de conjunto de caracteres
estándar, puede omitir el campo &lt;conjunto_de_caracteres&gt;, pero
recomendamos fuertemente que se incluya, especialmente para países con
varios estándares en competencia.

<p>
Varios ejemplos: 
<p>
<tscreen><verb>
Idioma		Territorio	Conjunto de caracteres	Directorio

Inglés		--------	ASCII			/usr/man/en
Inglés		Reino Unido	ASCII			/usr/man/en_GB
Inglés 		Estados Unidos	ASCII			/usr/man/en_US
Francés		Canadá	ISO8859-1		/usr/man/fr_CA
Francés		Francia		ISO8859-1		/usr/man/fr_FR
Alemán		Alemania	ISO646-DE		/usr/man/de_DE646de
Alemán		Alemania	ISO6937			/usr/man/de_DE6937
Alemán		Alemania	ISO8859-1		/usr/man/de_DE.88591
Alemán		Suiza		ISO646-CH		/usr/man/de_CH.646ch
Japonés		Japón		JIS			/usr/man/ja_JP.jis
Japonés		Japón		SJCS			/usr/man/ja_JP.sjis
Japonés		Japón	UJ (o EUC-J)		/usr/man/ja_JP.ujis
</verb></tscreen>

Las 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. &nl; Las secciones de páginas cat (cat[1-9]) que
contiene páginas del manual formateadas, también se encuentran dentro de los
subdirectorios /&lt;mandir&gt;/&lt;locale&gt;, pero no son requeridas ni
deben ser distribuidas en el lugar de las fuentes nroff de las páginas del
manual. &nl; Las 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. &nl;
Las páginas del sistema X Window deben tener el prefijo x en todos los
nombres de los archivos de las páginas. &nl; La 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. &nl; (Esta porción de este
estándar tambien se aplica más delante en la estructura opcional de
/var/catman). &nl; <p>

A continuación una descripción de cada sección.
<p>
<sect2>man1: Programas de usuario.

<p> Las 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í.

<p>
<sect2>man2: Llamadas al sistema.

<p> Esta sección describe todas las llamadas al sistema (requisiciones hacia
el kernel de <bf/Linux/ para realizar ciertas operaciones).

<p>
<sect2>man3: Subrutinas y funciones de librería.

<p> La 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.

<p>
<sect2>man4: Archivos especiales.

<p> Esta 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.

<p>
<sect2>man5: Formatos de archivos.

<p> Aquí 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.

<p>
<sect2>man6: Juegos.(Binarios Educativos)

<p> Esta 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.

<p>
<sect2>man7: Misceláneos

<p> Las 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í.

<p>
<sect2>man8: Administración del Sistema

<p> Aquí 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.

<p>
<sect2>man9: Funciones y variables internas del kernel

<p>Éste es utilizado para documentar el código fuente del kernel en los
Sistemas <bf/Linux/.


<sect1>/usr/sbin: Binarios de sistema estándar no-esenciales.

<p> Este directorio contiene cualesquier binario no-esencial utilizando
exclusivamente por el administrador del sistema. &nl; Los 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í. &nl; Tí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. &nl; Estos programas servidores son utilizados cuando se entra
en un estado que el System V conoce como &dquot;run level 2&dquot; (estado
multi-usuario) y el &dquot;run level 3&dquot; (estado en-red) o el estado que
el BSD conoce como &dquot;modo multi-usuario&dquot;. 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).

<p> Los programas administrativos instalados localmente deben estar
localizados en : /usr/local/sbin. <p>

<sect1>/usr/share : Información Independiente de Arquitectura.

<p> Cualquier especificación para /usr/share se incluirá en un documento
suplementario al <bf/FSSTND/. Note que es la opinión en consenso del
<bf/FSSTND/ que /usr/share no es necesario en la mayoría de los sistemas
<bf/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.

<p>
<sect1>/usr/src : Código fuente.
<p>
<tscreen><verb>
/usr/src --- Código fuente
	linux		 Código fuente para el kernel de Linux.
</verb></tscreen>

<p> Cualquier 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.&nl;
El 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.

<p>
<tscreen><verb>
	/usr/src/linux/include/asm-&lt;arch&gt;
	/usr/src/linux/include/linux
</verb></tscreen>

<p> usr/include debe contener enlaces a estos directorios, llamados asm y
/<bf/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. &nl;
/usr/src/linux puede también ser un enlace simbólico a un árbol de código
/fuente del kernel.
<p>

<sect>La Jerarquía /var <label id="sec5">
<p>
<tscreen><verb>
/var	Información variable

	adm		Info administrativa del sistema (obsoleto). Enlace simbólico hacia /var/log
	catman		Páginas del manual formateadas localmente
	lib		Información del estado de aplicaciones
	local		Información variable del software de /usr/local
	lock		Archivos de bloqueo
	log		Archivos de bitácora
	named		Archivos DNS, sólo red
	nis		Archivos base de datos NIS
	preserve	Archivos almacenados después de una falla de ex ó vi 
	run		Archivos relevantes a procesos ejecutándose
	spool		Directorios de trabajos en fila para realizarse después
	tmp		Archivos temporales, utilizado para mantener /tmp pequeño
</verb></tscreen>


<p> var 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. &nl;
Algunas 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.

<p> var 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.

<p> Si /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.
<p>

<sect1>/var/adm : Bitácora del sistema y archivos contables (obsoleto)

<p> Este 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.

<p> utmp se ha movido a /var/run. Todos los archivos bitácoras se han movido
a /var/log incluyen en el archivo wtmp.

<p> El soporte de empaquetado de distribuciones se debe almacenar en
/var/lib/&lt;nombre&gt; .

<p> <bf/Nota/: 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. <p>

<sect1>/var/catman : Páginas del Manual Formateadas localmente (opcional)

<p> Este 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.

<p> Preformateé todas las páginas del manual dentro de /usr con el programa
(catman). &nl: 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. &nl; Se permita el almacenamiento temporal local de las
páginas del manual en /var/catman.

<p> La 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.

<p> Dada una página del manual sin formatear que normalmente aparece en
/usr/&lt;ruta1&gt;/man/man[1-9], la versión formateada almacenada temporal
debe ir en /var/catman/&lt;ruta2&gt;/cat[1-9], donde &lt;ruta2&gt; es
&lt;ruta1&gt;. Los componentes &lt;ruta2&gt; y &lt;ruta1&gt; están ausentes
en el caso de /usr/man y /var/catman. <p>

Por ejemplo, /usr/man/man1/ls.1 se formatea en /var/catman/cat1/ls.1 y
/usr/X11R6/man/&lt;locale&gt;/man3/XtClass.3x lo hace en
/var/catman/X11R6/&lt;locale&gt;/cat3/XtClass.3x . <p>

Las páginas del manual escritas en /var/catman/cat[1-9] pueden
eventualmente, transferirse a /usr/&lt;ruta&gt;/cat[1-9] ó expirarse. De
igual forma las páginas del manual formateadas dentro de
/usr/&lt;ruta&gt;/cat[1-9] pueden expirarse si no son accesadas en un
periodo de tiempo. <p>

Si vienen páginas del manual preformateadas con un sistema <bf/Linux/ en un
medio sólo-lectura. (p. ej. un COROM), deben estar instaladas en
/usr/&lt;ruta&gt;/cat[1-9]. /var/catman está reservado como un lugar de
almacenamiento temporal para páginas de manual formateados. <p>

<sect1>/var/lib : Información de Estado de Aplicaciones.
<p>
<tscreen><verb>
/var/lib.- Información de Estado de Aplicaciones

	emacs		Directorio del estado de Emacs
	games		Información variable de juegos(archivos de marcadores)
	news		Archivos variables de Cnews/INN
	texmf		Información variable asociada con TeX
	xdm		Archivos de autenticación y bitácoras de error del manejador de despliegues X
</verb></tscreen>

<p> var/lib/&lt;nombre&gt; es el lugar apropiado para el soporte de
/empaquetamiento de todas las distribuciones. Diferentes distribuciones de
/<bf/Linux/ pueden utilizar diferentes nombres por supuesto.
<p>

<sect2>/var/lib/emacs

<p> El directorio del estado <bf/GNU Emacs/, el lugar donde los archivos de
información independiente de la arquitectura, que <bf/Emacs/ modifica cuando
se ejecuta, debe ser /var/lib. En el presente, <bf/Emacs/ sólo localiza su
directorio de archivos de bloqueo bajo el directorio de estado (en
&lt;direstado&gt;/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 <bf/Emacs/ para hacer este cambio (antes de
compilar). <p>

<sect2>/var/lib/games

<p> Así 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. <p>

<sect2>/var/lib/news

<p> var/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.
<p>

<sect2>/var/lib/texmf

<p> var/lib/texmf se debe usar para almacenar la información variable
/asociada con <bf/TeX/. Particularmente, en /var/lib/texmf/fonts se
/almacenarán todas las fuentes tipográficas que son generadas
/automáticamente por MakeTeXPK.

<p> Debe 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 <bf/TeX/
de Karl Berry distribuidas desde ftp.cs.umb.edu:pub/tex &#91;La razón de
mencionarlos aquí es que son el estándar de facto en las instalaciones
<bf/UNIX/, estas herramientas son ampliamente usadas entre la comunidad
<bf/Linux/]. Si se utiliza otra distribución de <bf/TeX/, se debe hacer un
enlace desde el directorio de fuentes apropiado hacia /usr/lib/texmf/fonts).

<p> El MakeTeXPK que se distribuye con dvipsk colocará los archivos .pk en
fonts/pk/&lt;dispositivo&gt;/&lt;nombre_de_la_fuente&gt;, (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.

<p>
<sect2>/var/lib/xdm
<p>
/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.

<p>
<sect1>/var/local : Información variable del software que está en /usr/local

<p> Este 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. <p>

<sect1>/var/lock : Archivos de Bloqueo

<p> Los archivos de bloqueo deben almacenarse dentro de una estructura del
directorio de /var/lock.

<p> Para preservar la habilidad de montar /usr sólo-lectura, no se deberá
colocar los archivos de bloqueo en la partición /usr.

<p> Los 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.

<p> El formato usado para los archivos de bloqueo de dispositivo en
<bf/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.

<p> Por 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.

<p> Entonces 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). <p>

<sect1>/var/log : Archivos bitácora y directorios

<p> Este directorio contiene archivos bitácora misceláneos. la mayoría de
los archivos bitácora se deben escribir en este directorio o subdirectorios
apropiados. <p>

<tscreen><verb>
	lastlog		Registro del último acceso de cada usuario
	messages	Mensajes del sistema desde syslogd
	wtmp		Registro de todos los accesos y salidas
</verb></tscreen>

<p> Se 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).

<p>
<sect1>/var/named : Archivos DNS

<p> Este directorio contiene todos los archivos de trabajo del servidor de
nombres Internet, named. &nl: 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. <p>

<sect1>/var/nis : Archivos de bases de datos del servicio de información de
red (NIS)

<p> El 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.

<p>

<sect1>/var/preserve:Archivos guardados después de una colisión o una
terminación inesperada de ex ó vi

<p> Este directorio contiene los archivos que son almacenados ante cualquier
terminación no-esperada de ex, vi, ó de alguno de sus clones.

<p>
<sect1>/var/run : Archivos variables de tiempo de ejecución

<p> Este 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.

<p> Los archivos identificados de proceso (PID), que estaban originalmente
/etc, se deben colocar en /var/run. La convención de nomenclatura de
archivos PID es &lt;nombre-programa&gt;.pid, por ejemplo el archivo PID de
crond se llama /var/run/crond.pid.

<p> El 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.

<p> Los 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.

<p> El archivo utmp, que almacena información acerca de quién está
actualmente utilizando el sistema, se localiza en este subdirectorio.

<p> Los programas que mantengan sockets transitorios de dominio <bf/UNIX/,
deben colocarlos en este directorio.

<p>
<sect1>/var/spool : Directorios de fila de trabajos para procesamiento posterior

<p> var/spool es tradicionalmente utilizado para la información local de
/máquina que es enviada para procesarse después, hacia o desde subsistemas
/<bf/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.

<p>
<tscreen><verb>
/var/spool
	at		Trabajos de at
	cron		Trabajos de cron
	lpd		Directorio de impresora * 
	mail		Archivos caja-postal(buzón) de los usuarios
	mqueue		Fila del correo saliente
	news		Directorio de noticias *
	rwhod		Archivos rwhod
	smail		Directorio de smail *
	uucp		Directorio de UUCP
</verb></tscreen>
<p>
<bf/Nota/: * Significa  fila de trabajos para proceso posterior.

<p> Los archivos de bloqueo UUCP deben localizarse en /var/lock. Véa la
sección acerca de /var/lock. <p>

<sect2>/var/spool/lpd
<p>
<tscreen><verb>
/var/spool/lpd --- Directorio de fila  de trabajos para proceso posterior o impresión
	&lt;impresora&gt;		Directorio que tiene la fila específica de esta impresora
</verb></tscreen>

<p> El 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 &lt;impresora&gt; de la impresora especifica y se debe llamar
lock. <p>

<sect1>/var/tmp : Archivos temporales, utilizando para mantener /tmp pequeño.

<p> Los 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).

<p> La información almacenada en /var/tmp típicamente se limpia en una
&dquot;forma definida localmente&dquot; pero usualmente menos frecuentemente
que /tmp. Se puede encontrar información sobre directorios temporales en la
selección dedicada a /tmp (arriba).

<p> Debe existir un enlace simbólico desde /usr/tmp hacia var/tmp por
razones de compatibilidad. <p>

<sect>Razonamientos adicionales y asuntos sin resolver <label id="sec6">

<p> Esta sección discute varias áreas que pueden requerir mayor explicación.

<p>
<sect1>¿Qué es esencial?

<p> La 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.

<p>
<sect1>Red

<p> La 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 &dquot;paquete&dquot;,
sino una parte integral de la mayoría de la máquinas <bf/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.

<p> <sect2>/bin :Cualquier cosa que algún usuario querrá utilizar y que es
también considerado vital. <p>

	<code>hostname, netstat, ping</code>

<sect2>/sbin :Cualquier cosa que sólo root necesita y se considere vital.
<p>
	<code>arp, ifconfig, route</code>

<sect2>/usr/bin : Algúnos binarios que algún usuario querrá utilizar y que
no son vitales. <p>

	<code>finger, rep, rlogin, telnet, etc.</code>

<sect2> /usr/sbin : Algúnos binarios sólo para el administrador que no son
vitales. <p>

	<code>in.ftpd, inetd, lpd, portmap, etc.</code>

<p> Aunque 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. <p>

Los archivos de configuración para la red pertenecen a /etc.

<p>
<sect1>Estructuras independientes de la arquitectura

<p> El 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
<bf/Linux/, pero con el tiempo, veremos que <bf/Linux/ incluirá otras
arquitecturas y otros sistemas similares a <bf/UNIX/. <p>

<bf/Nota/: 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á
&dquot;apuntada&dquot; a través de uso de enlaces símbolos desde otras áreas
del sistema de archivos, tales como /usr/man, /usr/lib/&lt;algo&gt;, etc...
Aún se trabaja en las especificaciones de /usr/share.

<p>
<sect1>Enlaces Simbólicos.

<p> Hay 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 <bf/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.

<p> Está 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.

<p> Similarmente, 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.

<p> Algunos sistemas además enlazarán /tmp a /var/&lt;algo&gt; si la
partición raíz se vuelve muy pequeña (ó es muy pequeña). Hay más ejemplos de
&dquot;buenos&dquot; 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. <p>

<sect1>Binarios Compilados Estáticamente.

<p> <bf/Linux/ 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.

<p> Los grandes sistemas <bf/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.

<p> En 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.

<p>
<sect>La lista del correo del <bf/FSSTND/

<p> La lista del correo del <bf/FSSTND/ se encuentra en
&lt;Linux-fsstnd@ucsd.edu&gt;. Esta lista estaba originalmente localizada en
&lt;Linux-activists@niksula.hut.fi&gt; &dquot;Mail Net&dquot; como el canal
<bf/FSSTND/. (Para subscribirse a la lista mande correo
&lt;listserv@ucsd.edu&gt; con el mensaje &dquot;ADD Linux-fsstnd&dquot;). &nl;
Gracias a Operaciones de Red en la Universidad de California en San Diego
quien nos permitió utilizar su excelente servidor de listas de correo. &nl;

<p>
<sect>Reconocimientos:
<p>

Se debe dar crédito por este texto a las activistas <bf/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. <p>

Deseo también dar real crédito a aquellos desarrolladores que han visto que
el dar a <bf/Linux/ un arreglo común del sistema de archivos es algo que
expandirá el desarrollo del sistema operativo <bf/Linux/. Deseo también la
valentía y perseverancia de aquellos desarrolladores de <bf/Linux/ quienes
comenzaron a seguir este estándar aún antes de que fuera completado. <p>

Los que contribuyeron originalmente:
<p>
<tscreen><verb>
Drew Eckhard		(US)	drew@colorado.edu
Brondon S. Allbery	(US)	bsa@kf8nh.wariat.org
Ian Jackson		(UK)	ijackson@cus.cam.ac.uk
Rik Faith		(US)	faith@cs.unc.edu
Iar Mc Cloghrie		(US)	ian@ucsd.edu
Stephen Harris		(UK)	sweh@spuddy.mew.co.uk
Daniel Quilan		(US)	Daniel.Quinlan@linux.org
Fred N. van Kemper	(US)	waltje@infomagic.com
Mike Sangrey		(US)	mike@sojurn.lns.pa.us
Jhon A. Martir		(US)	jmartin@csc.com
David H. Silber		(US)	dhs@glowworm.firefly.com
Chris Netcalf		(US)	metcalf@lcs.mit.edu
Theodore Tsó		(US)	tytso@athena.mit.edu
Ian Murdock		(US)	imurdock@debian.org
Stephen Tweedie		(UK)	sct@dcs.ed.ac.uk
David C. Niemi		(US)	niemid@clarck.net

</verb></tscreen>
<tscreen>
<code>
Estructura del sistema de archivos de Linux			Abril 1996

</code>
</tscreen>
</article>
