Windows:la explicación de un laico para "todo es un archivo":¿en qué se diferencia de Windows?

¿Cómo marca la diferencia aquí la filosofía de "Todo es un archivo"?

Lo explicaré ampliando mis tres puntos anteriores, en detalle.

Respuesta larga, parte 1:unidades frente a archivos de dispositivos

Digamos que su lector de tarjetas CF aparece como E: bajo Windows y /dev/sdc bajo Linux. ¿Qué diferencia práctica hace?

No es solo una pequeña diferencia de sintaxis.

En Linux, puedo decir dd if=/dev/zero of=/dev/sdc para sobrescribir el contenido de /dev/sdc con ceros.

Piensa en lo que eso significa por un segundo. Aquí tengo un programa de espacio de usuario normal (dd(1) ) que pedí leer datos desde un dispositivo virtual (/dev/zero ) y escribe lo que lee en un dispositivo físico real (/dev/sdc ) a través del sistema de archivos Unix unificado. dd no sabe que está leyendo y escribiendo en dispositivos especiales. Funcionará igual de bien en archivos normales o en una combinación de dispositivos y archivos, como veremos a continuación.

No hay una manera fácil de poner a cero el E: drive en Windows, porque Windows hace una distinción entre archivos y unidades, por lo que no puede usar los mismos comandos para manipularlos. Lo más cercano que puede obtener es hacer un formato de disco sin la opción de formato rápido, que pone a cero la mayoría del contenido de la unidad, pero luego escribe un nuevo sistema de archivos encima. ¿Qué sucede si no quiero un nuevo sistema de archivos? ¿Qué pasa si realmente quiero que el disco se llene con nada más que ceros?

Seamos generosos y digamos que realmente queremos un nuevo sistema de archivos en E: . Para hacer eso en un programa en Windows, tengo que llamar a una API de formato especial.⁴ En Linux, no necesita escribir un programa para acceder a la funcionalidad de "formatear disco" del sistema operativo. Simplemente ejecute el programa de espacio de usuario apropiado para el tipo de sistema de archivos que desea crear:mkfs.ext4 , mkfs.xfs , o lo que tengas. Estos programas escribirán un sistema de archivos en cualquier archivo o /dev nodo que pasas.

Porque mkfs Los programas de tipo en los sistemas Unixy funcionan en archivos sin hacer distinciones artificiales entre dispositivos y archivos normales, lo que significa que puedo crear un sistema de archivos ext4 dentro de un archivo normal en mi caja de Linux:

$ dd if=/dev/zero of=myfs bs=1k count=1k
$ mkfs.ext4 -F myfs

Eso crea literalmente una imagen de disco de 1 MiB en el directorio actual, llamada myfs . Luego puedo montarlo como si fuera cualquier otro sistema de archivos externo:

$ mkdir mountpoint
$ sudo mount -o loop myfs mountpoint
$ grep $USER /etc/passwd > mountpoint/my-passwd-entry
$ sudo umount mountpoint

Ahora tengo una imagen de disco ext4 con un archivo llamado my-passwd-entry en él que contiene el /etc/passwd de mi usuario entrada.

Si quiero, puedo enviar esa imagen a mi tarjeta CF:

$ sudo dd if=myfs of=/dev/sdc1

O bien, puedo empaquetar esa imagen de disco, enviársela por correo y dejar que la escriba en un medio de su eligiendo, como una memoria USB:

$ gzip myfs
$ echo "Here's the disk image I promised to send you." | 
  mutt -a myfs.gz -s "Password file disk image" [email protected]

Todo esto es posible en Linux⁵ porque no existe una distinción artificial entre archivos, sistemas de archivos y dispositivos. Muchas cosas en los sistemas Unix son archivos, o se accede a través del sistema de archivos para que parecen archivos, o de alguna otra manera se parecen lo suficiente a los archivos para que puedan ser tratados como tales.

El concepto de sistema de archivos de Windows es una mezcolanza; hace distinciones entre directorios, unidades y recursos de red. Hay tres sintaxis diferentes, todas combinadas en Windows:..FOOBAR similar a Unix sistema de ruta, letras de unidad como C: y rutas UNC como \SERVERPATHFILE.TXT . Esto se debe a que es una acumulación de ideas de Unix, CP/M, MS-DOS y LAN Manager, en lugar de un único diseño coherente. Es por eso que hay tantos caracteres ilegales en los nombres de archivo de Windows.

Unix tiene un sistema de archivos unificado, con todo accedido por un único esquema común. Para un programa que se ejecuta en una caja de Linux, no hay diferencia funcional entre /etc/passwd , /media/CF_CARD/etc/passwd y /mnt/server/etc/passwd . Los archivos locales, los medios externos y los recursos compartidos de red se tratan de la misma manera.⁶

Windows puede lograr fines similares a mi ejemplo de imagen de disco anterior, pero debe usar programas especiales escritos por programadores extraordinariamente talentosos. Esta es la razón por la que hay tantos programas de tipo "DVD virtual" en Windows. La falta de una función básica del sistema operativo ha creado un mercado artificial para que los programas llenen el vacío, lo que significa que hay un montón de personas compitiendo para crear el mejor programa de tipo DVD virtual. No necesitamos este tipo de programas en los sistemas *ix, porque simplemente podemos montar una imagen de disco ISO utilizando un dispositivo de bucle.

Lo mismo ocurre con otras herramientas como los programas de limpieza de discos, que tampoco necesitamos en los sistemas Unix. ¿Quiere que el contenido de su tarjeta CF se codifique irremediablemente en lugar de simplemente ponerlo a cero? Vale, usa /dev/random como fuente de datos en lugar de /dev/zero :

$ sudo dd if=/dev/random of=/dev/sdc

En Linux, no seguimos reinventando esas ruedas porque las características principales del sistema operativo no solo funcionan lo suficientemente bien, funcionan tan bien que se usan de forma generalizada. Un esquema típico para iniciar una caja de Linux involucra una imagen de disco virtual, solo por ejemplo, creada usando técnicas como las que muestro arriba.⁷

Creo que es justo señalar que si Unix hubiera integrado la E/S de TCP/IP en el sistema de archivos desde el principio, no tendríamos el netcat vs socat vs Ncat vs nc desorden, cuya causa fue la misma debilidad de diseño que condujo a la proliferación de herramientas de borrado y creación de imágenes de disco en Windows:falta de una instalación de sistema operativo aceptable.

Respuesta larga, parte 2:Tuberías como archivos virtuales

A pesar de sus raíces en DOS, Windows nunca ha tenido una rica tradición de línea de comandos.

Esto no quiere decir que Windows no tiene una línea de comandos, o que carece de muchos programas de línea de comandos. Windows incluso tiene un shell de comandos muy poderoso en estos días, apropiadamente llamado PowerShell.

Sin embargo, hay efectos colaterales de esta falta de una tradición de línea de comandos. Obtienes herramientas como DISKPART lo cual es casi desconocido en el mundo de Windows, porque la mayoría de la gente realiza particiones de disco y demás a través del complemento Computer Management MMC. Luego, cuando necesite crear un script para la creación de particiones, encontrará que DISKPART no fue hecho realmente para ser impulsado por otro programa. Sí, puede escribir una serie de comandos en un archivo de script y ejecutarlo a través de DISKPART /S scriptfile , pero es todo o nada. Lo que realmente querer en tal situación es algo más como GNU parted , que aceptará comandos individuales como parted /dev/sdb mklabel gpt . Eso permite que su secuencia de comandos maneje los errores paso a paso.

¿Qué tiene que ver todo esto con “todo es un archivo”? Fácil:las canalizaciones convierten la E/S del programa de línea de comandos en "archivos", de algún tipo. Los conductos son flujos unidireccionales, no de acceso aleatorio como un archivo de disco normal, pero en muchos casos la diferencia no tiene importancia. Lo importante es que puede adjuntar dos programas desarrollados de forma independiente y hacer que se comuniquen a través de texto simple. En ese sentido, cualquier par de programas diseñados con Unix Way en mente pueden comunicarse.

En aquellos casos en los que realmente necesite un archivo, es fácil convertir la salida del programa en un archivo:

$ some-program --some --args > myfile
$ vi myfile

Pero, ¿por qué escribir la salida en un archivo temporal cuando la filosofía de "todo es un archivo" le ofrece una mejor manera? Si todo lo que quiere hacer es leer la salida de ese comando en un vi búfer del editor, vi puede hacer eso por usted directamente. Del vi modo "normal", diga:

:r !some-program --some --args

Eso inserta la salida de ese programa en el búfer del editor activo en la posición actual del cursor. Debajo del capó, vi está usando tuberías para conectar la salida del programa a un fragmento de código que usa las mismas llamadas al sistema operativo que usaría para leer un archivo. No me sorprendería si los dos casos de :r — es decir, con y sin ! — ambos usaron el mismo ciclo de lectura de datos genéricos en todas las implementaciones comunes de vi . No puedo pensar en una buena razón para no hacerlo.

Esta no es una característica reciente de vi , o; se remonta claramente a la antigua ed(1) editor de texto.⁸

Esta poderosa idea aparece una y otra vez en Unix.

Para un segundo ejemplo de esto, recuerda mi mutt comando de correo electrónico anterior. La única razón por la que tuve que escribir eso como dos comandos separados es que quería que el archivo temporal se llamara *.gz , para que el archivo adjunto de correo electrónico tenga el nombre correcto. Si no me importara el nombre del archivo, podría haber usado la sustitución de procesos para evitar crear el archivo temporal:

$ echo "Here's the disk image I promised to send you." | 
  mutt -a <(gzip -c myfs) -s "Password file disk image" [email protected]

Eso evita lo temporal al convertir la salida de gzip -c en un FIFO (que es como un archivo) o un /dev/fd objeto (que es similar a un archivo). (Bash elige el método en función de las capacidades del sistema, ya que /dev/fd no está disponible en todas partes).

Para una tercera forma en que esta poderosa idea aparece en Unix, considere gdb en sistemas Linux. Este es el depurador utilizado para cualquier software escrito en C y C++. Los programadores que vienen a Unix desde otros sistemas miran gdb y casi invariablemente se quejan de eso, "¡Puaj, es tan primitivo!" Luego van a buscar un depurador de GUI, encuentran uno de varios que existen y felizmente continúan con su trabajo... a menudo sin darse cuenta de que la GUI solo ejecuta gdb debajo, proporcionando una bonita concha en la parte superior. No hay depuradores de bajo nivel que compitan en la mayoría de los sistemas Unix porque no hay necesidad de que los programas compitan en ese nivel. Todo lo que necesitamos es una buena herramienta de bajo nivel en la que todos podamos basar nuestras herramientas de alto nivel, si esa herramienta de bajo nivel se comunica fácilmente a través de conductos.

Esto significa que ahora tenemos una interfaz de depuración documentada que permitiría el reemplazo directo de gdb , pero desafortunadamente, el principal competidor de gdb no tomó el camino de baja fricción.

Aún así, es al menos posible que algún futuro gdb el reemplazo caería de forma transparente simplemente clonando su interfaz de línea de comandos. Para lograr lo mismo en una caja de Windows, los creadores de la herramienta reemplazable habrían tenido que definir algún tipo de complemento formal o API de automatización. Eso significa que no sucede excepto en los programas más populares, porque es mucho trabajo construir una interfaz de usuario de línea de comandos normal y una API de programación completa.

Esta magia sucede gracias a la omnipresente IPC basada en texto.

Aunque el kernel de Windows tiene conductos anónimos al estilo de Unix, es raro ver que los programas de usuario normales los usen para IPC fuera de un shell de comandos, porque Windows carece de esta tradición de crear todos los servicios principales en una versión de línea de comandos primero y luego construir la GUI en encima de ella por separado. Esto lleva a no poder hacer algunas cosas sin la GUI, que es una de las razones por las que hay tantos sistemas de escritorio remoto para Windows, en comparación con Linux:Windows es muy difícil de usar sin la GUI.

Por el contrario, es común administrar remotamente cajas Unix, BSD, OS X y Linux a través de SSH. ¿Y cómo funciona eso, te preguntarás? SSH conecta un socket de red (que es como un archivo) a un pseudo tty en /dev/pty* (que es como un archivo). Ahora su sistema remoto está conectado a su sistema local a través de una conexión que se adapta tan perfectamente a Unix Way que puede canalizar datos a través de la conexión SSH, si es necesario.

¿Tienes una idea de cuán poderoso es este concepto ahora?

Un flujo de texto canalizado es indistinguible de un archivo desde la perspectiva de un programa, excepto que es unidireccional. Un programa lee de una canalización de la misma manera que lee de un archivo:a través de un descriptor de archivo. Los FD son absolutamente fundamentales para Unix; el hecho de que los archivos y las canalizaciones usen la misma abstracción para E/S en ambos debería indicarle algo.⁹

El mundo de Windows, que carece de esta tradición de comunicaciones de texto simple, se las arregla con interfaces OOP pesadas a través de COM o .NET. Si necesita automatizar dicho programa, también debe escribir un programa COM o .NET. Esto es un poco más difícil que configurar una tubería en una caja de Unix.

Los programas de Windows que carecen de estas complicadas API de programación solo pueden comunicarse a través de interfaces empobrecidas como el portapapeles o Archivo/Guardar seguido de Archivo/Abrir.

Respuesta larga, parte 3:El registro frente a los archivos de configuración

La diferencia práctica entre el registro de Windows y la forma Unix de configuración del sistema también ilustra los beneficios de la filosofía de "todo es un archivo".

En los sistemas de tipo Unix, puedo ver la información de configuración del sistema desde la línea de comandos simplemente examinando los archivos. Puedo cambiar el comportamiento del sistema modificando esos mismos archivos. En su mayor parte, estos archivos de configuración son solo archivos de texto sin formato, lo que significa que puedo usar cualquier herramienta en Unix para manipularlos que pueda funcionar con archivos de texto sin formato.

Crear secuencias de comandos en el registro no es tan fácil en Windows.

El método más fácil es realizar los cambios a través de la GUI del Editor del Registro en una máquina y luego aplicar ciegamente esos cambios a otras máquinas con regedit a través de *.reg archivos Eso no es realmente "secuencias de comandos", ya que no le permite hacer nada condicionalmente:es todo o nada.

Si los cambios de su registro necesitan alguna cantidad de lógica, la siguiente opción más fácil es aprender PowerShell, que básicamente equivale a aprender la programación del sistema .NET. Sería como si Unix solo tuviera Perl, y tuvieras que hacer todo ad hoc administración del sistema a través de él. Ahora, soy un fanático de Perl, pero no todos lo son. Unix le permite usar cualquier herramienta que le guste, siempre que pueda manipular archivos de texto sin formato.

Notas al pie:

1. Plan 9 arregló este paso en falso de diseño, exponiendo E/S de red a través de /net sistema de archivos virtual.

Bash tiene una característica llamada /dev/tcp que permite E/S de red a través de funciones regulares del sistema de archivos. Dado que es una característica de Bash, más bien una característica del kernel, no es visible fuera de Bash o en sistemas que no usan Bash en absoluto. Esto muestra, por contraejemplo, por qué es una buena idea hacer que todos los recursos de datos sean visibles a través del sistema de archivos.

1. Por "Windows moderno", me refiero a Windows NT y todos sus descendientes directos, que incluyen Windows 2000, todas las versiones de Windows Server y todas las versiones de Windows orientadas al escritorio desde XP en adelante. Utilizo el término para excluir las versiones de Windows basadas en DOS, siendo Windows 95 y sus descendientes directos, Windows 98 y Windows ME, además de sus predecesores de 16 bits.

Puede ver la distinción por la falta de un sistema de E/S unificado en estos últimos sistemas operativos. No puede pasar un socket TCP/IP a ReadFile() en Windows 95; solo puede pasar sockets a las API de Windows Sockets. Consulte el artículo seminal de Andrew Schulman, Windows 95:lo que no es para profundizar más en este tema.

1. No te equivoques, /dev/null es un dispositivo kernel real en sistemas de tipo Unix, no solo un nombre de archivo en mayúsculas y minúsculas, como es el equivalente superficial NUL en Windows.

Aunque Windows intenta evitar que cree un NUL archivo, es posible eludir esta protección con un simple engaño, engañando a la lógica de análisis de nombre de archivo de Windows. Si intenta acceder a ese archivo con cmd.exe o Explorer, Windows se negará a abrirlo, pero puede escribir en él a través de Cygwin, ya que abre archivos utilizando métodos similares al programa de ejemplo, y puede eliminarlo mediante un truco similar.

Por el contrario, Unix felizmente le permitirá rm /dev/null , siempre que tenga acceso de escritura a /dev , y le permite recrear un nuevo archivo en su lugar, todo sin engaños, porque ese nodo de desarrollo es solo otro archivo. Si bien falta ese nodo de desarrollo, el dispositivo nulo del kernel aún existe; simplemente es inaccesible hasta que recreas el nodo de desarrollo a través de mknod .

Incluso puede crear nodos de desarrollo de dispositivos nulos adicionales en otro lugar:no importa si lo llama /home/grandma/Recycle Bin , siempre que sea un nodo de desarrollo para el dispositivo nulo, funcionará exactamente igual que /dev/null .

1. En realidad hay dos API de "formato de disco" de alto nivel en Windows:SHFormatDrive() y Win32_Volume.Format() .

Hay dos para muy... bueno... Windows especie de razón. El primero le pide al Explorador de Windows que muestre su cuadro de diálogo normal "Formatear disco", lo que significa que funciona en cualquier versión moderna de Windows, pero solo mientras un usuario está conectado de forma interactiva. El otro se puede llamar en segundo plano sin la entrada del usuario, pero no se agregó a Windows hasta Windows Server 2003. Así es, el comportamiento central del sistema operativo se ocultó detrás de una GUI hasta 2003, en un mundo donde Unix envió mkfs desde el día 1.

Mi copia de Unix V5 de 1974 incluye /etc/mkfs , un ejecutable PDP-11 enlazado estáticamente de 4136 bytes. (Unix no obtuvo vinculación dinámica hasta finales de la década de 1980, por lo que no es como si hubiera una gran biblioteca en otro lugar haciendo todo el trabajo real). Su código fuente, incluido en la imagen del sistema V5 como /usr/source/s2/mkfs.c — es un programa C de 457 líneas completamente autónomo. Ni siquiera hay #include declaraciones!

Esto significa que no solo puede examinar lo que mkfs lo hace a un alto nivel, puede experimentar con él utilizando el mismo conjunto de herramientas con el que se creó Unix, al igual que Ken Thompson, hace cuatro décadas. Prueba eso con Windows. Lo más cerca que puede llegar hoy es descargar el código fuente de DOS, lanzado por primera vez en 2014 , que encontrará equivale a solo un montón de fuentes de ensamblaje. Solo se compilará con herramientas obsoletas que probablemente no tenga a mano y, al final, obtendrá su propia copia de DOS 2.0, un sistema operativo mucho menos potente que el Unix V5 de 1974, a pesar de que se lanzó casi una década después.

(¿Por qué hablar de Unix V5? Porque es el sistema Unix completo más antiguo que aún está disponible. Las versiones anteriores aparentemente se perdieron en el tiempo. Hubo un proyecto que reconstruyó un Unix de la era V1/V2, pero parece que falta mkfs , a pesar de la existencia de la página del manual V1 vinculada anteriormente, lo que demuestra que debe haber existido en algún lugar, en algún momento. O aquellos que armaron este proyecto no pudieron encontrar una copia existente de mkfs para incluir, o apesta para encontrar archivos sin find(1) , que tampoco existe en ese sistema. :) )

Ahora, podrías estar pensando:“¿No puedo simplemente llamar a format.com ? ¿No es lo mismo en Windows que llamar a mkfs? en Unix? Por desgracia, no, no es lo mismo, por varias razones:

- First, `format.com` wasn't designed to be scripted. It prompts you to "press ENTER when ready", which means you need to send an Enter key to its input, or it'll just hang.

- Then, if you want anything more than a success/failure status code, you have to open its standard output for reading, which is [far more complicated on Windows than it has to be](http://msdn.microsoft.com/en-us/library/windows/desktop/ms682499%28v=vs.85%29.aspx). (On Unix, everything in that linked article can be accomplished with a simple [`popen(3)`](http://linux.die.net/man/3/popen) call.)

- Having gone through all this complication, the output of `format.com` is harder to parse for computer programs than the output of `mkfs`, being intended primarily for human consumption.

- If you trace what `format.com` does, you find that it does a bunch of complicated calls to [`DeviceIoControl()`](http://msdn.microsoft.com/en-us/library/windows/desktop/aa363216%28v=vs.85%29.aspx), `ufat.dll`, and such. It is not simply opening a device file and writing a new filesystem onto that device. This is the sort of design you get from [a company that employs 126000 people](https://news.microsoft.com/facts-about-microsoft/#EmploymentInfo), and needs to *keep* employing them.

1. Cuando hablo de dispositivos de bucle, hablo solo de Linux en lugar de Unix en general porque los dispositivos de bucle no son portátiles entre sistemas de tipo Unix. Existen mecanismos similares en OS X, BSD, etc., pero la sintaxis varía un poco.

2. En los días en que las unidades de disco eran del tamaño de lavadoras y costaban más que el automóvil de lujo del jefe de departamento, los grandes laboratorios de computación compartían una mayor proporción de su espacio de disco colectivo en comparación con los entornos informáticos modernos. La capacidad de injertar de forma transparente un disco remoto en el sistema de archivos local hizo que estos sistemas distribuidos fueran mucho más fáciles de usar. Aquí es donde obtenemos /usr/share , por ejemplo.

En contraste con Windows, donde un disco remoto generalmente se asigna a una letra de unidad o se debe acceder a él a través de una ruta UNC, en lugar de integrarse de manera transparente en el sistema de archivos local. Las letras de unidad le ofrecen pocas opciones para la expresión simbólica; hace P: referirse al espacio "público" en BigServer, o al directorio de "paquetes" en el servidor espejo de software? Las rutas UNC significan que debe recordar en qué servidor se encuentran sus archivos remotos, lo que se vuelve difícil en una organización grande con cientos o miles de servidores de archivos.

Windows no obtuvo enlaces simbólicos hasta Windows Vista, lanzado en 2007, que introdujo enlaces simbólicos NTFS. Los enlaces simbólicos de Windows son un poco más poderosos que los enlaces simbólicos de Unix, una característica de Unix desde 1977, ya que también pueden apuntar a un recurso compartido de archivos remoto, no solo a una ruta local. Unix lo hizo de manera diferente, a través de NFS en 1984, que se basa en la función de punto de montaje preexistente de Unix, que ha tenido desde el principio.

Entonces, dependiendo de cómo se mire, Windows se quedó atrás de Unix por aproximadamente 2 o 3 décadas.

Incluso entonces, los enlaces simbólicos no son una parte normal de la experiencia de un usuario de Windows, por un par de razones.

Primero, solo puede crearlos con el programa de línea de comando hacia atrás MKLINK . No puede crearlos desde el Explorador de Windows, mientras que los equivalentes de Unix al Explorador de Windows normalmente hacen te permite crear enlaces simbólicos.

En segundo lugar, la configuración predeterminada de Windows evita que los usuarios normales creen enlaces simbólicos, lo que requiere que ejecute el shell de comandos como administrador o le dé permiso al usuario para crearlos a través de una ruta oscura en una herramienta que el usuario promedio nunca ha visto, y mucho menos conoce. cómo utilizar. (Y a diferencia de la mayoría de los problemas de privilegios de administrador en Windows, UAC no es de ayuda en este caso).

1. Las cajas de Linux no siempre usan una imagen de disco virtual en la secuencia de arranque. Hay un montón de maneras diferentes de hacerlo.

2. man ed

3. Por cierto, los descriptores de socket de red también son FD debajo.