"Todo es un archivo" es un poco simplista. "Todo aparece en algún lugar del sistema de archivos " está más cerca de la marca, e incluso entonces, es más un ideal que una ley de diseño de sistemas.
Por ejemplo, los sockets de dominio Unix no son archivos, pero sí aparecen en el sistema de archivos. Puede ls -lun socket de dominio para mostrar sus atributos, catdatos a / desde uno, modificar su control de acceso a través de chmod, etc.
Pero, a pesar de que los sockets de red TCP / IP regulares se crean y manipulan con las mismas llamadas al sistema de sockets BSD que los sockets de dominio Unix, los sockets TCP / IP no se muestran en el sistema de archivos, ¹ aunque no haya una razón especialmente buena para que esto deba ser cierto.
Otro ejemplo de objetos que no son archivos que aparecen en el sistema de archivos es el /procsistema de archivos de Linux . Esta característica expone una gran cantidad de detalles sobre la operación en tiempo de ejecución del kernel al espacio del usuario , principalmente como archivos virtuales de texto sin formato. Muchas /procentradas son de solo lectura, pero muchas /proctambién se pueden escribir, por lo que puede cambiar la forma en que se ejecuta el sistema utilizando cualquier programa que pueda modificar un archivo. Lamentablemente, aquí tenemos una no idealidad: los Unixes de tipo BSD generalmente se ejecutan sin ellos/proc , y los Unix de System V exponen mucho menos a través de lo /procque Linux lo hace.
No puedo contrastar eso con MS Windows
Primero, gran parte del sentimiento que puede encontrar en línea y en los libros acerca de que Unix tiene que ver con la E / S de archivos y que Windows está "roto" en este sentido es obsoleto. Windows NT solucionó mucho de esto.
Las versiones modernas de Windows tienen un sistema de E / S unificado, al igual que Unix, por lo que puede leer datos de red desde un socket TCP / IP a través ReadFile()de la API específica de Windows Sockets WSARecv(), si lo desea. Esto es exactamente paralelo al Unix Way , donde puede leer desde un socket de red con la read(2)llamada genérica del sistema Unix o la llamada específica de recv(2)sockets.
Sin embargo, Windows todavía no puede llevar este concepto al mismo nivel que Unix, incluso aquí en 2018. Hay muchas áreas de la arquitectura de Windows a las que no se puede acceder a través del sistema de archivos, o que no se pueden ver como archivos. Algunos ejemplos:
Conductores
El subsistema de controladores de Windows es fácilmente tan rico y poderoso como el de Unix, pero para escribir programas para manipular controladores, generalmente debe usar el Kit de controladores de Windows , lo que significa escribir código C o .NET.
En sistemas operativos tipo Unix, puede hacer mucho a los controladores desde la línea de comandos. Es casi seguro que ya ha hecho esto, aunque solo sea redirigiendo la salida no deseada a /dev/null.³
Comunicación entre programas.
Los programas de Windows no se comunican fácilmente entre sí.
Los programas de línea de comandos de Unix se comunican fácilmente a través de flujos de texto y tuberías. Los programas GUI a menudo se crean sobre los programas de línea de comandos o exportan una interfaz de comando de texto, de modo que los mismos mecanismos de comunicación basados en texto simples también funcionan con los programas GUI.
El registro
Unix no tiene un equivalente directo del registro de Windows. La misma información se dispersa a través del sistema de archivos, la mayor parte en /etc, /procy /sys.
Si no ve que los controladores, las tuberías y la respuesta de Unix al registro de Windows tienen algo que ver con "todo es un archivo", siga leyendo.
¿Cómo marca la diferencia "Todo es un archivo" aquí?
Explicaré eso ampliando mis tres puntos anteriores, en detalle.
Respuesta larga, parte 1: Unidades frente a archivos de dispositivo
Digamos que su lector de tarjetas CF aparece como E:en Windows y /dev/sdcen 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/sdcque sobrescriba el contenido de /dev/sdccon ceros.
Piensa en lo que eso significa por un segundo. Aquí tengo un programa de espacio de usuario normal ( dd(1)) al que le pedí leer datos desde un dispositivo virtual ( /dev/zero) y escribir lo que leyó en un dispositivo físico real ( /dev/sdc) a través del sistema de archivos Unix unificado. ddno sabe si está leyendo y escribiendo en dispositivos especiales. Funcionará también 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 la E:unidad 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 Formato rápido, que pone a cero la mayor parte del contenido de la unidad, pero luego escribe un nuevo sistema de archivos encima. ¿Qué pasa 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 nuevo 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 "disco de formato" del sistema operativo. Que acaba de ejecutar el programa de espacio de usuario apropiado para el tipo de sistema de archivos que desea crear: mkfs.ext4, mkfs.xfso lo que sea. Estos programas escribirán un sistema de archivos en cualquier archivo o /devnodo que pase.
Debido a que los mkfsprogramas de tipo en sistemas Unixy funcionan en archivos sin hacer distinciones artificiales entre dispositivos y archivos normales, 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
Literalmente crea 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-entryque contiene la /etc/passwdentrada de mi usuario .
Si quiero, puedo enviar esa imagen a mi tarjeta CF:
$ sudo dd if=myfs of=/dev/sdc1
O bien, puedo empacar esa imagen de disco, enviársela por correo y dejar que la escriba en un medio de su elección, 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" you@example.com
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 se vean como archivos, o de alguna otra manera se vean lo suficientemente similares a los archivos para que puedan ser tratados como tales.
El concepto de Windows del sistema de archivos es una mezcolanza; distingue entre directorios, unidades y recursos de red. Hay tres sintaxis diferentes, todas combinadas en Windows: el sistema de ..\FOO\BARruta similar a Unix , las letras de unidad similares C:y las rutas UNC similares \\SERVER\PATH\FILE.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 solo diseño coherente. Es por eso que hay tantos caracteres ilegales en los nombres de archivos de Windows .
Unix tiene un sistema de archivos unificado, con acceso a todo mediante un único esquema común. A un programa que se ejecuta en una máquina Linux, no hay diferencia funcional entre /etc/passwd, /media/CF_CARD/etc/passwdy /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 al ejemplo de mi imagen de disco anterior, pero debe usar programas especiales escritos por programadores poco talentosos. Es por eso que hay tantos programas de tipo "DVD virtual" en Windows . La falta de una característica central 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 que compiten para crear el mejor programa virtual de tipo DVD. No necesitamos tales programas en los sistemas * ix, porque solo podemos montar una imagen de disco ISO usando un dispositivo de bucle .
Lo mismo ocurre con otras herramientas como los programas de limpieza de disco , que tampoco necesitamos en los sistemas Unix. ¿Desea que el contenido de su tarjeta CF se revuelva irremediablemente en lugar de simplemente ponerlo a cero? De acuerdo, utilícelo /dev/randomcomo fuente de datos en lugar de /dev/zero:
$ sudo dd if=/dev/random of=/dev/sdc
En Linux, no seguimos reinventando tales ruedas porque las características principales del sistema operativo no solo funcionan lo suficientemente bien, sino que funcionan tan bien que se usan de manera generalizada. Un esquema típico para arrancar una caja de Linux implica una imagen de disco virtual, por ejemplo, creada usando técnicas como las que muestro arriba.
Creo que es justo señalar que si Unix hubiera integrado las E / S TCP / IP en el sistema de archivos desde el principio, no tendríamos netcatvs socatvs Ncatvs mess , cuya causa fue la misma debilidad de diseño que condujo a proliferación de herramientas de barrido y generación de imágenes de disco en Windows: falta de un sistema operativo aceptable.nc
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 tenga una línea de comando o que carezca de muchos programas de línea de comando. Windows incluso tiene un shell de comando muy poderoso en estos días, apropiadamente llamado PowerShell .
Sin embargo, hay efectos secundarios de esta falta de una tradición de línea de comandos. Obtiene herramientas como las DISKPARTque es casi desconocida en el mundo de Windows, porque la mayoría de las personas realizan particiones de disco y cosas similares a través del complemento Computer Management MMC. Luego, cuando necesite crear una secuencia de comandos para la creación de particiones, DISKPARTverá que en realidad no fue creado para ser manejado por otro programa. Sí, puede escribir una serie de comandos en un archivo de script y ejecutarlo DISKPART /S scriptfile, pero es todo o nada. Lo que realmente quieres en tal situación es algo más como GNUparted , que aceptará comandos individuales como parted /dev/sdb mklabel gpt. Eso permite que su script maneje los errores paso a paso.
¿Qué tiene que ver todo esto con "todo es un archivo"? Fácil: las canalizaciones hacen que la E / S del programa de línea de comandos se convierta en "archivos" de una especie. Las tuberías son flujos unidireccionales , no de acceso aleatorio como un archivo de disco normal, pero en muchos casos la diferencia no tiene consecuencias. Lo importante es que puede adjuntar dos programas desarrollados de forma independiente y hacer que se comuniquen a través de un texto simple. En ese sentido, cualquiera de los dos programas diseñados pensando en Unix Way puede comunicarse.
En aquellos casos en los que realmente necesita 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 "todo es un archivo" le da una mejor manera? Si todo lo que quiere hacer es leer la salida de ese comando en un vibúfer de editor, vipuede hacerlo directamente. Desde el modo vi"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ó, viestá usando tuberías para conectar la salida del programa a un bit de código que usa las mismas llamadas del sistema operativo que usaría para leer un archivo. No me sorprendería si los dos casos de :r, es decir, con y sin el !, ambos usaran el mismo bucle 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 tampoco es una característica reciente de vi; se remonta al antiguo ed(1)editor de texto.
Esta poderosa idea aparece una y otra vez en Unix.
Para un segundo ejemplo de esto, recuerda mi muttcomando de correo electrónico anterior. La única razón por la que tuve que escribir eso como dos comandos separados es porque quería que se nombrara el archivo temporal *.gz, para que el archivo adjunto de correo electrónico se nombrara correctamente. Si no me importara el nombre del archivo, podría haber usado la sustitución del proceso 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" you@example.com
Eso evita lo temporal al convertir la salida de gzip -cen un FIFO (que es como un archivo) o un /dev/fdobjeto (que es como un archivo). (Bash elige el método en función de las capacidades del sistema, ya /dev/fdque no está disponible en todas partes).
Por una tercera forma, esta poderosa idea aparece en Unix, considere gdben los sistemas Linux. Este es el depurador utilizado para cualquier software escrito en C y C ++. Los programadores que vienen a Unix desde otros sistemas lo miran gdby casi invariablemente se quejan al respecto: "¡Qué asco, es tan primitivo!" Luego van a buscar un depurador de GUI, encuentran uno de los varios que existen y continúan felizmente con su trabajo ... a menudo nunca se gdbdan cuenta de que la GUI solo se ejecuta debajo, proporcionando un bonito caparazón encima. No hay depuradores competitivos de bajo nivel en la mayoría de los sistemas Unix porque no hay necesidad de que los programas compitan a 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 tuberías.
Esto significa que ahora tenemos una interfaz de depurador documentada que permitiría el reemplazo directo de gdb, pero desafortunadamente, el principal competidor gdb no tomó el camino de baja fricción .
Aún así, al menos es posible que algún gdbreemplazo futuro caiga de manera transparente simplemente clonando su interfaz de línea de comando. 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 para los programas más populares, porque es mucho trabajo construir tanto una interfaz de usuario de línea de comando normal como una API de programación completa.
Esta magia ocurre a través de la gracia del IPC basado en texto generalizado .
Aunque el kernel de Windows tiene canales anónimos de estilo 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 centrales en una versión de línea de comandos primero, y luego construir la GUI en la parte superior 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 de forma remota a través de SSH. ¿Y cómo funciona eso, preguntas? SSH conecta un zócalo 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 coincide tan bien con el Unix Way que puede canalizar datos a través de la conexión SSH , si es necesario.
¿Te estás dando una idea de cuán poderoso es este concepto ahora?
Una secuencia de texto entubada es indistinguible de un archivo desde la perspectiva de un programa, excepto que es unidireccional. Un programa lee desde una tubería de la misma manera que lee desde un archivo: a través de un descriptor de archivo . Los FD son absolutamente esenciales para Unix; el hecho de que los archivos y las tuberías usen la misma abstracción para E / S en ambos debería decirle algo.
El mundo de Windows, al carecer de esta tradición de comunicaciones de texto simples, se conforma 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 bastante más difícil que configurar una tubería en una caja de Unix.
Los programas de Windows que carecen de estas API de programación complicadas 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 configuración de sistema de Unix Way también ilustra los beneficios de la filosofía "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 puedan funcionar con archivos de texto sin formato.
Crear un script para el registro no es tan fácil en Windows.
El método más fácil es realizar sus cambios a través de la GUI del Editor del Registro en una máquina, luego aplicar esos cambios ciegamente a otras máquinas con archivos regeditvia*.reg . Eso no es realmente "scripting", ya que no te permite hacer nada condicionalmente: es todo o nada.
Si sus cambios en el registro necesitan algo 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 toda la administración del sistema ad hoc 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:
El Plan 9 solucionó este paso en falso del diseño, exponiendo las E / S de red a través del /netsistema de archivos virtual .
Bash tiene una característica llamada/dev/tcp que permite la E / S de red a través de funciones regulares del sistema de archivos. Como es una función de Bash, más bien una función del núcleo, 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 visibles todos los recursos de datos a través del sistema de archivos.
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 esos últimos sistemas operativos. No puede pasar un socket TCP / IP ReadFile()en Windows 95; solo puede pasar sockets a las API de Windows Sockets. Consulte el artículo seminal de Andrew Schulman, Windows 95: Qué no es para profundizar en este tema.
No se equivoque, /dev/nulles un dispositivo de núcleo real en sistemas de tipo Unix, no solo un nombre de archivo con carcasa especial, como es el equivalente superficial NULen Windows.
Aunque Windows intenta evitar que cree un NULarchivo, es posible omitir esta protección con un simple truco , engañando la lógica de análisis de nombre de archivo de Windows. Si intenta acceder a ese archivo con cmd.exeo Explorer, Windows se negará a abrirlo, pero puede escribirle a través de Cygwin, ya que abre archivos usando métodos similares al programa de ejemplo, y puede eliminarlo a través de trucos similares .
Por el contrario, Unix felizmente le permitirá rm /dev/null, siempre y cuando tenga acceso de escritura /dev, y le permitirá recrear un nuevo archivo en su lugar, todo sin trucos, porque ese nodo de desarrollo es solo otro archivo. Mientras falta ese nodo de desarrollo, el dispositivo nulo del núcleo todavía existe; es inaccesible hasta que vuelva a crear 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.
En realidad, hay dos API de "disco de formato" de alto nivel en Windows: SHFormatDrive()y Win32_Volume.Format().
Hay dos por un muy ... bueno ... tipo de razón de Windows . 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 puede llamar en segundo plano sin intervención del usuario, pero no se agregó a Windows hasta Windows Server 2003. Así es, el comportamiento del sistema operativo central estaba oculto detrás de una GUI hasta 2003, en un mundo donde Unix se envió mkfs desde el día 1 .
Mi copia de Unix V5 de 1974 incluye /etc/mkfsun ejecutable PDP-11 enlazado estáticamente de 4136 bytes . (Unix no obtuvo un enlace dinámico hasta fines de la década de 1980 , por lo que no es como si hubiera una gran biblioteca en algún 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 457 completamente autónomo. programa de línea C. ¡Ni siquiera hay #includedeclaraciones!
Esto significa que no solo puede examinar lo que mkfshace a un alto nivel, sino que también puede experimentar con el mismo conjunto de herramientas con el que se creó Unix, al igual que usted es Ken Thompson , hace cuatro décadas. Intenta eso con Windows. Lo más cercano que puede llegar hoy es descargar el código fuente de DOS , lanzado por primera vez en 2014 , que encuentra solo una pila de fuentes de ensamblaje . Solo se construirá con herramientas obsoletas que probablemente no tendrá 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 primer sistema completo de Unix 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 faltar mkfs, a pesar de la existencia de la página del manual de V1 vinculada anteriormente 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 mkfspara incluir, o apestaba en encontrar archivos sin find(1), que tampoco existe en ese sistema . :))
Ahora, podría estar pensando: "¿No puedo llamar format.com? ¿No es lo mismo en Windows que llamar mkfsa Unix?" Por desgracia, no, no es lo mismo, por varias razones:
Primero, format.comno fue diseñado para ser guionado. Le indica que "presione ENTER cuando esté listo", lo que significa que necesita enviar una tecla Enter a su entrada, o simplemente se bloqueará.
Luego, si desea algo más que un código de estado de éxito / falla, debe abrir su salida estándar para leer, que es mucho más complicado en Windows de lo que debe ser . (En Unix, todo en ese artículo vinculado se puede lograr con una simple popen(3)llamada).
Habiendo pasado por toda esta complicación, la salida de format.comes más difícil de analizar para los programas de computadora que la salida de mkfs, destinada principalmente al consumo humano.
Si se desplaza por lo que format.comhace, usted encontrará que lo hace un montón de llamadas complicado DeviceIoControl(), ufat.dlly tales. No es simplemente abrir un archivo de dispositivo y escribir un nuevo sistema de archivos en ese dispositivo. Este es el tipo de diseño que obtienes de una empresa que emplea a 126000 personas y necesita seguir empleándolos.
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 .
En los días en que las unidades de disco eran del tamaño de las lavadoras y costaban más que el automóvil de lujo del jefe del departamento, los grandes laboratorios de computadoras compartirían una mayor proporción de su espacio de disco colectivo en comparación con los entornos informáticos modernos. La capacidad de injertar transparentemente un disco remoto en el sistema de archivos local hizo que tales sistemas distribuidos fueran mucho más fáciles de usar. Aquí es donde llegamos /usr/share, por ejemplo.
Contraste Windows, donde un disco remoto generalmente se asigna a una letra de unidad o se debe acceder 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; ¿se P:refiere al espacio "público" en BigServer o al directorio "paquetes" en el servidor espejo del software? Las rutas UNC significan que debe recordar en qué servidor están 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 potentes 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 hizo eso de manera diferente, a través de NFS en 1984 , que se basa en la característica de punto de montaje preexistente de Unix , que ha tenido desde el principio.
Entonces, dependiendo de cómo lo veas, Windows siguió a Unix por aproximadamente 2 o 3 décadas.
Incluso entonces, los enlaces simbólicos no son una parte normal de la experiencia del usuario de Windows, por un par de razones.
Primero, solo puede crearlos con el programa de línea de comando hacia atrásMKLINK . No se puede crear desde el Explorador de Windows, mientras que los equivalentes de Unix a Windows Explorer normalmente no permiten crear enlaces simbólicos.
En segundo lugar, la configuración predeterminada de Windows impide 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 su usuario promedio nunca ha visto, y mucho menos sabe 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).
Los cuadros de Linux no siempre usan una imagen de disco virtual en la secuencia de arranque. Hay muchas formas diferentes de hacerlo .
man ed
Los descriptores de socket de red son FD debajo, también, por cierto.