Consejos para estructurar el directorio home (2023)

 (unixdigest.com)
2 puntos por GN⁺ 2024-04-21 | 1 comentarios | Compartir por WhatsApp

Consejos para estructurar el directorio home

  • Estructurar u ordenar directorios no es muy distinto de estructurar u ordenar cualquier otra cosa, y la clave es hacerlo de la manera que más sentido tenga para uno mismo
  • Al manejar la organización, todo puede salirse de control muy rápido
  • El objetivo principal del orden es la eficiencia: deberías poder encontrar fácil y rápidamente lo que buscas, y guardar fácil y rápidamente lo que necesitas guardar

Archivos y directorios ocultos predeterminados

  • En mi directorio home tengo todos los archivos ocultos predeterminados que forman parte de un sistema operativo Unix moderno, como .config, .aliases, .profile, .gnupg, .mozilla, etc.
  • Preferiría que todas las aplicaciones respetaran XDG_CONFIG_HOME, pero no me meto demasiado ni me preocupo tanto por eso
  • En el pasado mantuve $HOME en Git, y es una excelente forma de gestionar los dotfiles
  • Sigo poniendo todos los dotfiles en Git para conservar el historial de cambios, pero dejo tal cual solo los dotfiles que funcionan igual en los distintos sistemas que uso
  • Los dotfiles específicos de cada configuración se guardan en el directorio dotfiles y se usan enlaces simbólicos

Organización general de archivos y directorios

  • Los archivos y directorios generales se organizan principalmente de dos maneras: por "categoría" y por "fecha"
  • Estructura básica de directorios:
    • bin
    • data
    • edata
    • mnt
    • usr/dotfiles
  • Los directorios Desktop y Downloads se dejan como están (parece que la mayoría de las aplicaciones los imponen)
  • El directorio bin se usa para guardar scripts de shell y ejecutables binarios personales (excepto los instalados mediante el gestor de paquetes)
  • El directorio mnt se usa para varios puntos de montaje, como tarjetas SD, discos USB y almacenamiento compartido usado en el homelab
  • Nunca hago montaje automático; uso scripts de shell para montar
  • El directorio usr/dotfiles se gestiona con Git junto con dotfiles generales como .aliases, y usa enlaces simbólicos a los archivos relacionados del directorio dotfiles

Organización del directorio de datos

  • Los directorios data y edata son los dos directorios principales donde se guarda todo el material
  • Estos dos directorios son datasets de ZFS que corren sobre un pool de espejado de discos, separado de la instalación raíz
  • Aprovechando ZFS, se usan snapshots y también envío y recepción de ZFS de forma periódica para respaldar fácilmente en almacenamiento de red
  • La diferencia entre data y edata es que edata es un dataset de cifrado nativo de ZFS
  • El cifrado es bueno para la privacidad, pero añade una capa terrible de complejidad sobre una jerarquía de sistema de archivos que ya es compleja, y el cifrado de ZFS tiene bugs
  • Se recomienda encarecidamente respaldar siempre los datos importantes en varias soluciones de almacenamiento y ubicaciones distintas
  • No se usa almacenamiento en la nube para cosas importantes

Consejos adicionales

  • La regla básica para nombrar archivos y directorios es que debería ser fácil identificar qué son solo con ver el nombre
  • Si no puedes saber de qué trata un archivo sin abrirlo, deberías abrirlo de inmediato y cambiarle el nombre por uno más significativo para la próxima vez que lo veas
  • Si dejas archivos y directorios sin ordenar ni atender, luego se vuelve muy difícil corregirlo
  • Se usan nombres de archivo con descripciones largas cuando hace falta, para poder entender el contenido sin abrir el archivo

La opinión de GN⁺

  • Este artículo ofrece consejos prácticos sobre cómo ordenar y organizar la estructura de directorios. En particular, resulta interesante la forma de administrar separando directorios cifrados y no cifrados mediante datasets de ZFS.

  • Personalmente, creo que es buena idea guardar cifrados los datos importantes. Sin embargo, como también tiene desventajas como la caída de rendimiento o el aumento de complejidad, parece mejor usarlo de forma selectiva según cada situación.

  • Además, también parece importante compartir con la familia la forma de acceder a los datos cifrados. Hace falta evitar perder los datos incluso si uno ya no puede acceder por un accidente u otra situación.

  • Para la gestión de datos personales, es muy importante establecer una estrategia de respaldos sistemática como la del autor. Seguir la regla de respaldo 3-2-1 y, más que depender del almacenamiento en la nube, aprovechar almacenamiento local distribuido físicamente también parece una buena opción.

  • Entre las herramientas open source útiles para organizar datos personales están Syncthing y Nextcloud. Si se aprovechan bien estas herramientas, parece posible lograr una gestión de datos personales ordenada y segura.

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-04-21
Opiniones de Hacker News

  • Odio que el directorio home se llene de desorden, y me molesta especialmente cuando una app cree que tiene que crear un directorio que ni siquiera está oculto en home.
    Lo que más me enfurece es ~/go, el directorio predeterminado de los módulos de Go. Lo odié tanto que durante años evité instalar o desarrollar apps en Go, pero al final tuve que usarlo; aunque se puede cambiar configurando GOPATH, como valor predeterminado es pésimo.

    • Lo peor son las herramientas CLI hechas en Mac que ignoran XDG. Como allá no es un concepto común, cada herramienta ensucia los dotfiles con su propio directorio, como .rustup, .mix, .npm, .yarn.
      Aun así, contaminar el directorio home sin siquiera tener la cortesía de ocultarse, como ~/go, es realmente descortés.
    • Creo que GOPATH en sí es un mal diseño. En vez de tener una estructura de directorios independiente por proyecto, como otros lenguajes, hace que cosas de proyectos no relacionados se mezclen en la misma estructura de directorios.
      Choca tanto con mi forma de organizar proyectos que fue la principal razón por la que dejé de interesarme en Go. Tal vez encaje mejor con quienes prefieren juntar varios proyectos no relacionados en un solo monorepo, pero no es mi estilo.
    • Consejo: no pongas tus archivos en $HOME. $HOME es el lugar que ensucian las apps; tus archivos pueden ir literalmente en cualquier otro lugar.
    • Hace mucho abandoné la idea de tener un directorio home limpio. Todo lo importante lo pongo dentro de un directorio sincronizado en home, como pCloud o Dropbox, y ahí dentro lo mantengo perfectamente organizado.
      .vimrc y .gitconfig los tengo como enlaces simbólicos a un repositorio Git. Así, no importa si el resto del directorio home es pura basura, y si una máquina muere puedo recuperarme en otra en cuestión de minutos.
    • Me habría gustado que Unix hubiera separado desde el principio, como estándar, el “directorio home donde las apps ponen todo lo que quieran” y el “directorio home donde el usuario guarda sus archivos”.

  • xdg-ninja me ayudó a reducir el problema de que la mayoría de las apps suelten archivos en el directorio home.
    En resumen, escanea los programas instalados y te dice si se pueden configurar para seguir el estándar XDG. No funciona con todo, pero muchas apps tienen esa opción.
    https://github.com/b3nj5m1n/xdg-ninja

  • No solo quiero orden, también quiero respaldar y portar todo de forma compacta entre máquinas.
    La carpeta .config es un gran dolor de cabeza para respaldos estratégicos, porque las apps meten ahí datos de sesión de varios gigabytes.
    Los “datos de sesión” no son “configuración”. La “configuración” de una app no puede pesar varios gigabytes.

    • A menos que le pida a un programa cambiar su configuración persistente, .config debería poder funcionar como solo lectura.
    • Totalmente de acuerdo. No entiendo por qué las apps usan .config como si fuera un almacén de datos de la app. Para eso existen .local y .cache.

  • Esto es tan personal que la solución del autor no me sirve, y mi solución probablemente tampoco le ayude mucho a otra gente.
    Mi directorio home está casi vacío. Todos mis archivos de trabajo están en OwnCloud, y la verdadera pregunta es cuál es la estructura de directorios dentro de OwnCloud. Los repositorios Git locales los tengo en una partición totalmente separada.
    Ahora que KeepassXC maneja las claves SSH, las claves de .ssh también pasaron a estar dentro del archivo de Keepass en OwnCloud. Se volvió súper simple, y ahora casi no hay nada en el directorio home que realmente me importe.

    • Lo único importante es la portabilidad al cambiar de sistema y separar el entorno laboral del personal.
      Después de iniciar sesión, con un solo comando debería poder sincronizar el conjunto de archivos adecuado según si el entorno actual es Linux, de trabajo, personal, de escritorio o servidor.
      Por ejemplo, nunca querría exportar a un sistema de trabajo variables de entorno como el endpoint de mi vault personal o ciertos tokens.
      Hace poco me pasé a home-manager del proyecto NixOS y se ve bastante prometedor. El lenguaje Nix es complejo, pero la abstracción para definir distintos entornos era justo lo que necesitaba, y puedo separar el contenido de archivos de trabajo/personales con ramas de Git.
    • Aun así, dejo .vimrc y .bashrc/.zshrc en home

  • La idea está bien, pero no me gusta la forma de dividir los medios en una estructura tipo familia. Con el tiempo parece que terminarás con montones de archivos duplicados y copias duplicadas editadas que se mezclan fácilmente, y podrías perder las versiones editadas
    Creo que es mejor organizar las fotos con palabras clave EXIF. Guardar los metadatos en la foto misma, quizá dentro del tipo MIME, y si está relacionada con la familia, etiquetarla como #family o #personx. Así las fotos quedan en carpetas por fecha, por ejemplo, y lo demás se edita con palabras clave en un programa como Adobe Bridge
    Para la estructura de nombres de archivos de documentos he probado tanto Date then Description.txt como Keyword Title or Description and then Date.txt. Para la fecha uso una fecha ISO en formato YYYY-MM-DD-hhmm para facilitar el ordenamiento, y -hhmm es opcional
    A veces quieres ordenar por tema, es decir, por palabra clave o título, pero cuando lo más importante es cuándo se registró, como en un log, conviene poner la fecha al principio
    Puede parecer innecesario porque la fecha también se guarda en el sistema, pero al mover archivos la fecha termina cambiando, y si cometes un error cambia aún más fácilmente. En cambio, la fecha dentro del nombre del archivo no cambia y también ayuda a ordenar listas

    • Un almacenamiento direccionado por contenido para cada tipo de medio parece ir en la dirección correcta para este problema. Idealmente sería una especie de overlay que solo haga referencias, sin cambiar la estructura de directorios ni la organización de archivos existente
      photoprism y photostructure no parecen preocuparse mucho por la estructura u organización de directorios, pero paperless (y variantes modernas como -ngx) es famoso por ser muy terco con su propia organización y por no querer respetar estructuras existentes
      Durante un tiempo usé camlistore/perkeep para fotos, pero Google Photos tiene una capacidad abrumadora para detectar quién aparece en cada foto, incluso considerando diferencias de edad. Mis dos hijos, que se llevan 8 años, se parecían muchísimo cuando tenían edades similares, y aun así distingue correctamente quién es quién. No sé si usa análisis facial o metadatos de las fotos, pero nunca los confundió. El problema es que no hay una forma razonable de sacar esa información de etiquetas fuera de Google Photos, aun pagando
      Creo que ya es momento de volver a mirar. No recuerdo si photostructure o photoprism intentan reconocimiento facial, pero aunque todavía no lo hagan, pronto podrían llegar a un nivel parecido al de Google Photos, o al menos ser lo bastante buenos como para dejar de depender de Google
      Documentos y fotos/videos, bien, ¿pero qué pasa con la música? Para bien o para mal, hace al menos unos 10 años que no administro directamente mi colección de música como archivos. ¿Hoy existen sistemas de biblioteca para música que estén más integrados con el contenido que simples “archivos en el disco”, al estilo paperless o photoprism?
    • Para administrar etiquetas arbitrarias de archivos, vale la pena probar TagSpaces https://www.tagspaces.org/ o TMSU https://tmsu.org/. No se limitan solo a archivos EXIF o ID3

  • Mi método es este
    Dejo los elementos relacionados con GUI en mayúscula y los relacionados con CLI en minúscula. Prefiero algo como ~/documents, pero como la gente de GUI insiste con las mayúsculas, lo acepto. Casi nunca tengo que mezclar ambos, así que no es un gran problema
    ~/dotfiles es mi directorio de dotfiles gestionado con Git. Creo enlaces simbólicos como ~/.zshrc -> dotfiles/zshrc. No uso software de gestión aparte; solo hago enlaces. Antes usaba ~/.dotfiles, pero creo que tiene más sentido dejarlo visible
    ~/projects es mi directorio de proyectos. ~/projects/test es para proyectos de prueba descartables, ~/projects/my para proyectos personales y ~/projects/company para proyectos de la empresa donde trabajo actualmente. A veces trabajo con varias empresas en algo parecido a freelance, así que necesito separarlos
    ~/tmp es el directorio para todo trabajo descartable. Tengo una función de shell llamada mkcdtmp que crea un directorio con la fecha actual, como ~/tmp/240419, y luego entra ahí. Es una forma realmente buena. Prefiero comprar discos grandes y dejar la basura más o menos ordenada, así que casi nunca limpio. Si necesito algo de ayer o del mes pasado, sé dónde está, y ha sido lo que más me ayudó a ordenar el trabajo temporal. Si hace falta también puedo crear ~/tmp/whatever, y de todos modos todo eso es material descartable
    No uso ~/Desktop. Casi tampoco uso ~/Documents y todavía tengo que encontrar una forma de organizarlo. Las notas cortas las tiro en el repositorio de GitHub que construye mi sitio web personal. Probé varias apps de notas, pero un sitio web simple en Markdown fue lo que mejor me funcionó
    Nunca logré organizar mi trabajo de forma muy estructurada. Siempre hay montones de basura dando vueltas hasta que eventualmente se convierten en algo útil, así que, en vez de pelear conmigo mismo, decidí convertir esa basura en basura ordenada
    En esencia, mi computadora es consumible. Todo lo que está en ~/projects está en Git, y ~/tmp es más bien caché o trabajo descartable de poca importancia. Intento organizarlo para que no tarde mucho restaurar desde un estado limpio. Reinstalo el OS desde cero con frecuencia y también cambio seguido de sistema operativo y de laptop; este método es el que mejor me funciona

    • Odio de verdad escribir cualquier cosa con mayúsculas. Sé que es solo presionar una tecla más, pero me resulta terriblemente molesto

  • Una de mis grandes quejas sobre el sistema de archivos es que demasiados directorios empiezan con D
    Desktop, Dev, Downloads, Documents, Dropbox, etc.
    Pensé en cambiar algo, pero como dice el autor, muchas aplicaciones son bastante tercas con este tema

    • Para evitar este problema uso /src

  • Uso una estructura bastante simple, pero que me funciona bien
    Debajo de projects/ creo carpetas por año como 2023/, 2024/, y a cada proyecto le pongo un prefijo de mes+día, como 0000-something/, 0312-other-project/, 0419-hn-comment/
    Cada año creo la carpeta del año, y cuando quiero dejar arriba proyectos de largo plazo, les pongo 0000 o dejo solo el día como 00
    Es simple y funciona en cualquier OS. En Linux sí uso un poco algunos scripts auxiliares
    También es fácil crear rápidamente el directorio al que voy a mover archivos desde la carpeta de descargas, y si mantienes el anidamiento en un solo nivel, es fácil encontrar cosas. Me parece mejor que un patrón como YYYY/MM/DD, donde aparece un nivel adicional para el mes

    • Uso un método parecido cuando organizo carpetas relacionadas en orden cronológico
      En el directorio de nivel superior normalmente dejo lo que estoy trabajando ahora. Es algo como “hoy” o “esta semana”
      Cuando lo archivo porque sale de esa ventana temporal, por ejemplo si es hoy creo una carpeta con un formato como 041924 y muevo ahí todos los archivos creados ese día
      Creo que, considerando una vida humana normal, no hace falta usar una cadena como 2024. No creo que vaya a vivir hasta 2100, y lo anterior a 2000 no es relevante, así que con 24 alcanza
      Como el tiempo sigue pasando, la cantidad de carpetas archivadas crece, pero son pequeñas y fáciles de encontrar. Funciona especialmente bien si todos los días creas archivos estándar que no son muy únicos
    • ¿No se podría usar la fecha de modificación de las carpetas? Se podrían ordenar
      projects/ | 01.01.2017
      something/ | 01.01.2024
      other-project/ | 01.01.2023
      hn-comment/ | 01.01.2022
    • Yo también terminé migrando a este enfoque, sumándole una estructura de carpetas con carácter de “proceso”. Habrá más datos duplicados, pero te protege la salud mental

  • Sobre backups, una vez intenté configurar una Mac nueva desde un backup de Time Machine, pero la Mac no pudo ver nada dentro del backup de Time Machine
    Al contactar al soporte de Apple, me dijeron que hay un bug raro en el que el proceso de instalación a veces inicializa el backup de Time Machine en vez de instalar desde el backup
    Por suerte tenía configurado Backblaze y me salvé, pero restaurar cientos de gigabytes tomó muchísimo tiempo
    Ahora uso backups de Time Machine, Backblaze e iCloud, y de vez en cuando empaqueto todo en un .tgz y lo subo a S3

  • En cuanto a guiones y guiones bajos en nombres de archivos y directorios, estoy totalmente de acuerdo con usar guiones
    Usar guiones al moverse en la terminal es tan práctico que creo que debería ser el estándar. Es mucho mejor que tener que escribir algo extra cada vez para seleccionar nombres de archivo con guion bajo, o lidiar con espacios

    • Esa es una pequeña cosa que me gusta de Lisp. Puedes nombrar variables como foo-bar-baz y no hace falta apretar Shift al escribirlas