Skip to content

Una spiegazione da profano per "Tutto è un file": cosa c'è di diverso da Windows?

Restate sintonizzati perché in questa recensione troverete il trovato che cercate.Questa recensione è stata analizzata dai nostri specialisti per garantire la qualità e l'accuratezza del nostro post.

Soluzione:

"Tutto è un file" è un po' banale. "Tutto appare da qualche parte nel filesystem" è più vicino al segno, e anche in questo caso, è più un ideale che una legge di progettazione del sistema.

Per esempio, i socket del dominio Unix non sono file, ma appaiono nel filesystem. È possibile ls -l un socket di dominio per visualizzarne gli attributi, modificarne il controllo di accesso via chmode su alcuni sistemi di tipo Unix (ad esempio macOS, ma non Linux) è possibile anche cat dati a/da uno di essi.

Ma, anche se i normali socket di rete TCP/IP sono creati e manipolati con le stesse chiamate di sistema BSD sockets dei socket di dominio Unix, i socket TCP/IP fanno non nel filesystem,¹ anche se non c'è una ragione particolarmente valida per cui ciò debba essere vero.

Un altro esempio di oggetti non-file che appaiono nel filesystem è il file system di Linux /proc filesystem di Linux. Questa funzione espone allo spazio utente una grande quantità di dettagli sulle operazioni di run-time del kernel, per lo più come file virtuali di testo semplice. Molti /proc sono di sola lettura, ma molti dei file /proc è anche scrivibile, quindi è possibile cambiare il modo in cui il sistema funziona utilizzando qualsiasi programma in grado di modificare un file. Ahimè, anche in questo caso abbiamo una non idealità: Gli Unix di tipo BSD generalmente funzionano senza /proce gli Unix di tipo System V espongono molto meno via /proc di quanto non faccia Linux.

Non posso contrapporlo a MS Windows

In primo luogo, gran parte del sentimento che si può trovare online e nei libri sul fatto che Unix sia tutto incentrato sull'I/O dei file e che Windows sia "rotto" in questo senso è obsoleto. Windows NT ha risolto molti di questi problemi.

Le versioni moderne di Windows hanno un sistema di I/O unificato, proprio come Unix, per cui è possibile leggere i dati di rete da un socket TCP/IP tramite ReadFile() piuttosto che tramite l'API specifica per i socket di Windows WSARecv()se lo si desidera. Questo è esattamente parallelo al modo Unix, dove è possibile leggere da un socket di rete con l'API generica read(2) o con la chiamata di sistema Unix generica o con l'API specifica per i socket recv(2) chiamata.²

Tuttavia, Windows non riesce ancora a portare questo concetto allo stesso livello di Unix, anche qui nel 2021. Ci sono molte aree dell'architettura di Windows a cui non si può accedere attraverso il filesystem, o che non possono essere viste come simili ai file. Alcuni esempi:

  1. Driver.

Il sottosistema dei driver di Windows è facilmente ricco e potente come quello di Unix, ma per scrivere programmi per manipolare i driver è generalmente necessario utilizzare il Windows Driver Kit, il che significa scrivere codice C o .NET.

Sui sistemi operativi di tipo Unix, è possibile fare molto sui driver dalla riga di comando. Quasi certamente lo avete già fatto, anche solo reindirizzando l'output indesiderato a /dev/null

  1. Comunicazione tra programmi.

I programmi Windows non comunicano facilmente tra loro.

I programmi Unix a riga di comando comunicano facilmente tramite flussi di testo e pipe. I programmi GUI sono spesso costruiti sopra i programmi a riga di comando o esportano un'interfaccia di comando testuale, in modo che gli stessi semplici meccanismi di comunicazione basati sul testo funzionino anche con i programmi GUI.

  1. Il registro di sistema.

Unix non ha un equivalente diretto del registro di Windows. Le stesse informazioni sono sparse nel filesystem, la maggior parte delle quali si trova in /etc, /proc e /sys.

Se non capite che i driver, le pipe e la risposta di Unix al registro di Windows hanno qualcosa a che fare con "tutto è un file", continuate a leggere.

In che modo la filosofia "Tutto è un file" fa la differenza in questo caso?

Lo spiegherò ampliando i tre punti precedenti, in dettaglio.

Risposta lunga, parte 1: Unità e file del dispositivo

Supponiamo che il lettore di schede CF appaia come E: sotto Windows e /dev/sdc sotto Linux. Che differenza pratica fa?

Non è solo una piccola differenza di sintassi.

Su Linux, posso dire dd if=/dev/zero of=/dev/sdc per sovrascrivere il contenuto di /dev/sdc con degli zeri.

Pensate a cosa significa questo per un secondo. Qui ho un normale programma in spazio utente (dd(1)) a cui ho chiesto di leggere i dati da un dispositivo virtuale (/dev/zero) e di scrivere ciò che ha letto su un dispositivo fisico reale (/dev/sdc) tramite il filesystem Unix unificato. dd non sa che sta leggendo e scrivendo su dispositivi speciali. Funzionerà anche su file normali o su un mix di dispositivi e file, come vedremo in seguito.

Non c'è un modo semplice per azzerare il parametro E: in Windows, perché quest'ultimo fa una distinzione tra file e unità, quindi non è possibile utilizzare gli stessi comandi per manipolarli. Il modo più semplice è quello di eseguire una formattazione del disco senza l'opzione di formattazione rapida, che azzera l'unità . più del contenuto dell'unità, ma poi vi scrive sopra un nuovo filesystem. Cosa succede se non voglio un nuovo filesystem? E se volessi davvero che il disco si riempisse solo di zeri?

Siamo generosi e diciamo che vogliamo davvero un nuovo filesystem su E:. Per farlo in un programma su Windows, devo chiamare una speciale API di formattazione.⁴ Su Linux, non è necessario scrivere un programma per accedere alla funzionalità "format disk" del sistema operativo. È sufficiente eseguire il programma dello spazio utente appropriato per il tipo di filesystem che si desidera creare: mkfs.ext4, mkfs.xfso altro. Questi programmi scriveranno un filesystem su qualsiasi file o file di tipo /dev . /devnodo passato.

Perché mkfs sui sistemi Unixy lavorano sui file senza fare distinzioni artificiali tra dispositivi e file normali, significa che posso creare un filesystem ext4 all'interno di un file normale sulla mia Linux box:

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

Questo crea letteralmente un'immagine disco da 1 MiB nella directory corrente, chiamata myfs. Posso quindi montarla come se fosse un qualsiasi altro filesystem esterno:

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

Ora ho un'immagine disco ext4 con un file chiamato my-passwd-entry che contiene il nome del mio utente /etc/passwd del mio utente.

Se voglio, posso inviare l'immagine alla mia scheda CF:

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

Oppure, posso impacchettare l'immagine del disco, spedirla a voi e lasciarvi scrivere su un supporto di tuo scelta, come una chiavetta 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]

Tutto questo è possibile su Linux⁵ perché non esiste una distinzione artificiale tra file, filesystem e dispositivi. Molte cose sui sistemi Unix o sono file, oppure sono accessibili attraverso il filesystem in modo che assomiglino a o, in qualche altro modo, hanno un aspetto sufficientemente simile a un file da poter essere trattati come tali.

Il concetto di filesystem di Windows è un hodgepodge; fa distinzione tra directory, unità e risorse di rete. Esistono tre diverse sintassi, tutte mescolate insieme in Windows: la sintassi Unix-like ..FOOBAR il sistema di percorsi, le lettere di unità come C:e i percorsi UNC come \SERVERPATHFILE.TXT. Questo perché si tratta di un insieme di idee provenienti da Unix, CP/M, MS-DOS e LAN Manager, piuttosto che di un progetto unico e coerente. È per questo che ci sono così tanti caratteri illegali nei nomi dei file di Windows.

Unix ha un filesystem unificato, con tutto ciò a cui si accede tramite un unico schema comune. Per un programma in esecuzione su una macchina Linux, non c'è alcuna differenza funzionale fra /etc/passwd, /media/CF_CARD/etc/passwde /mnt/server/etc/passwd. I file locali, i supporti esterni e le condivisioni di rete vengono trattati allo stesso modo.⁶

Windows può raggiungere scopi simili a quelli dell'esempio dell'immagine del disco, ma è necessario utilizzare programmi speciali scritti da programmatori di talento fuori dal comune. Questo è il motivo per cui ci sono così tanti programmi di tipo "DVD virtuale" su Windows. La mancanza di una caratteristica fondamentale del sistema operativo ha creato un mercato artificiale per i programmi che colmano il vuoto, il che significa che c'è un gruppo di persone che compete per creare il miglior programma di tipo DVD virtuale. Sui sistemi *ix non abbiamo bisogno di programmi di questo tipo, perché possiamo semplicemente montare un'immagine ISO del disco usando un dispositivo loop.

Lo stesso vale per altri strumenti come i programmi di pulizia del disco, di cui non abbiamo bisogno sui sistemi Unix. Volete che il contenuto della vostra scheda CF sia irrimediabilmente strapazzato invece che semplicemente azzerato? Bene, usate /dev/random come sorgente di dati invece di /dev/zero:

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

In Linux non si continuano a reinventare le ruote, perché le funzioni principali del sistema operativo non solo funzionano abbastanza bene, ma funzionano talmente bene da essere utilizzate in modo pervasivo. Un tipico schema per l'avvio di un sistema Linux prevede un'immagine di disco virtuale, per fare un esempio, creata con tecniche come quelle illustrate sopra.⁷

Mi sembra giusto sottolineare che se Unix avesse integrato l'I/O TCP/IP nel filesystem fin dall'inizio, non avremmo avuto il problema dell'I/O TCP/IP. netcat vs socat vs Ncat vs nc La causa è la stessa debolezza progettuale che ha portato alla proliferazione di strumenti di imaging e cancellazione dei dischi su Windows: la mancanza di un sistema operativo accettabile.

Risposta lunga, parte 2: le pipe come file virtuali

Nonostante le sue radici nel DOS, Windows non ha mai avuto una ricca tradizione di riga di comando.

Questo non vuol dire che Windows non abbia abbia una riga di comando, o che non abbia molti programmi a riga di comando. Windows ha persino una shell di comando molto potente, chiamata opportunamente PowerShell.

Tuttavia, questa mancanza di tradizione della riga di comando ha degli effetti a catena. Ci sono strumenti come DISKPART che è quasi sconosciuto nel mondo Windows, perché la maggior parte delle persone effettua il partizionamento del disco e simili attraverso lo snap-in MMC di Gestione computer. Poi, quando si ha la necessità di eseguire lo script per la creazione di partizioni, si scopre che DISKPART non è stato creato per essere guidato da un altro programma. Sì, è possibile scrivere una serie di comandi in un file di script ed eseguirli tramite DISKPART /S scriptfilema si tratta di un'operazione che non ha nulla a che vedere con la creazione di partizioni. Quello che davvero in una situazione del genere è qualcosa di più simile a GNU partedche accetta singoli comandi come parted /dev/sdb mklabel gpt. Questo permette allo script di gestire gli errori passo dopo passo.

Che cosa ha a che fare tutto questo con "tutto è un file"? Semplice: le pipe trasformano l'I/O dei programmi da riga di comando in una sorta di "file". Le pipe sono flussi unidirezionali, non ad accesso casuale come un normale file su disco, ma in molti casi la differenza non ha alcuna importanza. La cosa importante è che si possono collegare due programmi sviluppati in modo indipendente e farli comunicare tramite semplice testo. In questo senso, due programmi progettati con il metodo Unix possono comunicare.

Nei casi in cui si ha davvero bisogno di un file, è facile trasformare l'output del programma in un file:

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

Ma perché scrivere l'output in un file temporaneo quando la filosofia "tutto è un file" offre un modo migliore? Se l'unica cosa che si vuole fare è leggere l'output di quel comando in un file vi buffer dell'editor, vi può farlo direttamente. Dall'editor vi modalità "normale", diciamo:

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

Questo inserisce l'output del programma nel buffer dell'editor attivo nella posizione corrente del cursore. Sotto il cofano, vi utilizza le pipe per collegare l'output del programma a un pezzo di codice che utilizza le stesse chiamate al sistema operativo che userebbe per leggere da un file. Non sarei sorpreso se i due casi di :r - cioè con e senza l'elemento ! - usassero entrambi lo stesso ciclo generico di lettura dei dati in tutte le comuni implementazioni di vi. Non riesco a pensare a una buona ragione per non farlo.

Questa non è una caratteristica recente di vi, ma risale all'antico ed(1) editor di testo.⁸

Questa potente idea si ripresenta più volte in Unix.

Per un secondo esempio, ricordate il mio mutt di posta elettronica di cui sopra. L'unica ragione per cui ho dovuto scriverlo come due comandi separati è che volevo che il file temporaneo si chiamasse *.gzin modo che l'allegato all'e-mail fosse nominato correttamente. Se non mi interessava il nome del file, avrei potuto usare la sostituzione di processo per evitare di creare il file temporaneo:

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

Questo evita il temporaneo trasformando l'output di gzip -c in un FIFO (che è simile a un file) o in un file /dev/fd (che è simile a un file). (Bash sceglie il metodo in base alle capacità del sistema, dal momento che /dev/fd non è disponibile ovunque).

Per un terzo modo in cui questa potente idea appare in Unix, si consideri gdb sui sistemi Linux. Questo è il debugger utilizzato per qualsiasi software scritto in C e C++. I programmatori che arrivano a Unix da altri sistemi guardano a gdb e quasi invariabilmente se ne lamentano: "Che schifo, è così primitivo!". Poi vanno alla ricerca di un debugger GUI, ne trovano uno dei tanti esistenti e continuano felicemente il loro lavoro... spesso senza rendersi conto che la GUI esegue semplicemente gdb sotto di essa, fornendo una bella shell sopra di essa. Non ci sono debugger di basso livello concorrenti sulla maggior parte dei sistemi Unix perché non c'è bisogno di programmi che competano a quel livello. Tutto ciò di cui abbiamo bisogno è un buon strumento di basso livello su cui tutti possiamo basare i nostri strumenti di alto livello, se questo strumento di basso livello comunica facilmente tramite pipe.

Questo significa che ora abbiamo un'interfaccia documentata per il debugger che permette di sostituire in modo semplice e immediato gdbma sfortunatamente il principale concorrente di gdb non ha scelto la strada del basso attrito.

Tuttavia, è almeno possibile che qualche futuro gdb sostituzione si inserisca in modo trasparente semplicemente clonando la sua interfaccia a riga di comando. Per fare la stessa cosa su un sistema Windows, i creatori dello strumento sostituibile avrebbero dovuto definire una sorta di plugin formale o di API di automazione. Questo significa che non accade se non per i programmi più popolari, perché è molto impegnativo costruire sia una normale interfaccia utente a riga di comando che un'API di programmazione completa.

Questa magia avviene grazie alla grazia di un IPC pervasivo basato sul testo.

Sebbene il kernel di Windows disponga di pipe anonime in stile Unix, è raro che i normali programmi utente le utilizzino per l'IPC al di fuori di una shell di comando, perché Windows non ha la tradizione di creare tutti i servizi principali in una versione a riga di comando e poi di costruirci sopra l'interfaccia grafica separatamente. Questo porta all'impossibilità di fare alcune cose senza la GUI, ed è uno dei motivi per cui ci sono così tanti sistemi di desktop remoto per Windows, rispetto a Linux: Windows è molto difficile da usare senza la GUI.

Al contrario, è comune amministrare a distanza i sistemi Unix, BSD, OS X e Linux tramite SSH. E come funziona, vi chiederete? SSH collega un socket di rete (che è simile a un file) a una pseudo tty a /dev/pty* (che è simile a un file). Ora il vostro sistema remoto è connesso a quello locale attraverso una connessione che corrisponde così perfettamente a quella di Unix che, se necessario, potete inviare dati attraverso la connessione SSH.

Vi state facendo un'idea di quanto sia potente questo concetto?

Un flusso di testo in pipe è indistinguibile da un file dal punto di vista del programma, tranne per il fatto che è unidirezionale. Un programma legge da una pipe nello stesso modo in cui legge da un file: attraverso un descrittore di file. Gli FD sono assolutamente fondamentali per Unix; il fatto che file e pipe usino la stessa astrazione per l'I/O su entrambi dovrebbe dirvi qualcosa.⁹

Il mondo Windows, privo di questa tradizione di semplici comunicazioni testuali, si accontenta di pesanti interfacce OOP tramite COM o .NET. Se avete bisogno di automatizzare un programma di questo tipo, dovete anche scrivere un programma COM o .NET. Questo è un po' più difficile che configurare una pipe su un sistema Unix.

I programmi Windows che non dispongono di queste complicate API di programmazione possono comunicare solo attraverso interfacce impoverite come gli appunti o File/Salva seguito da File/Apri.

Risposta lunga, parte 3: Il registro e i file di configurazione

La differenza pratica tra il registro di Windows e il metodo Unix di configurazione del sistema illustra anche i vantaggi della filosofia "tutto è un file".

Nei sistemi di tipo Unix, è possibile esaminare le informazioni di configurazione del sistema dalla riga di comando semplicemente esaminando i file. Posso cambiare il comportamento del sistema modificando quegli stessi file. Per la maggior parte, questi file di configurazione sono semplici file di testo, il che significa che per manipolarli posso usare qualsiasi strumento di Unix in grado di lavorare con file di testo.

La manipolazione del registro di sistema non è altrettanto facile su Windows.

Il metodo più semplice è quello di apportare le modifiche attraverso la GUI dell'Editor del Registro di sistema su una macchina, quindi applicare ciecamente tali modifiche alle altre macchine con regedit tramite *.reg file. Questo non è un vero e proprio "scripting", poiché non consente di fare nulla in modo condizionato: o tutto o niente.

Se le modifiche al registro di sistema richiedono una certa logica, l'opzione più semplice è quella di imparare PowerShell, che in pratica equivale a imparare la programmazione di sistema .NET. Sarebbe come se su Unix ci fosse solo il Perl e si dovesse fare tutto quello che si vuole. ad hoc amministrazione di sistema ad hoc. Ora, io sono un fan del Perl, ma non tutti lo sono. Unix vi permette di usare qualsiasi strumento vi piaccia, purché sia in grado di manipolare file di testo.


Note a piè di pagina:

  1. Il Piano 9 ha corretto questo errore di progettazione, esponendo l'I/O di rete tramite il parametro /net filesystem virtuale.

Bash ha una funzione chiamata /dev/tcp che consente l'I/O di rete tramite le normali funzioni del filesystem. Poiché si tratta di una funzione di Bash e non del kernel, non è visibile al di fuori di Bash o su sistemi che non usano affatto Bash. Questo dimostra, con un controesempio, perché è una buona idea rendere tutte le risorse di dati visibili attraverso il filesystem.

  1. Per "Windows moderno" intendo Windows NT e tutti i suoi diretti discendenti, il che include Windows 2000, tutte le versioni di Windows Server e tutte le versioni di Windows orientate al desktop da XP in poi. Uso questo termine per escludere le versioni di Windows basate sul DOS, ovvero Windows 95 e i suoi diretti discendenti, Windows 98 e Windows ME, oltre ai loro predecessori a 16 bit.

La distinzione si può notare dalla mancanza di un sistema di I/O unificato in questi ultimi sistemi operativi. Non è possibile passare un socket TCP/IP a ReadFile() su Windows 95; si possono passare solo socket alle API Windows Sockets. Per un approfondimento di questo argomento si veda l'articolo fondamentale di Andrew Schulman, Windows 95: What It's Not.

  1. Non commettete errori, /dev/null è un vero e proprio dispositivo del kernel sui sistemi di tipo Unix, non solo un nome di file con caratteri speciali, come l'equivalente superficiale NUL in Windows.

Sebbene Windows cerchi di impedire la creazione di un file NUL è possibile aggirare questa protezione con un semplice trucco, ingannando la logica di parsing dei nomi di file di Windows. Se si tenta di accedere al file con cmd.exe o con Explorer, Windows si rifiuterà di aprirlo, ma si potrà scrivere su di esso tramite Cygwin, che apre i file con metodi simili a quelli del programma di esempio, e si potrà cancellare con un trucco simile.

Al contrario, Unix vi permetterà volentieri di rm /dev/nulla patto che abbiate accesso in scrittura a /deve vi permetterà di ricreare un nuovo file al suo posto, il tutto senza trucchi, perché quel nodo dev è solo un altro file. Mentre il nodo dev è mancante, il dispositivo nullo del kernel esiste ancora; è solo inaccessibile finché non si ricrea il nodo dev tramite mknod.

È anche possibile creare altri nodi dev di dispositivo nullo altrove: non importa se si chiama /home/grandma/Recycle Binpurché sia un nodo di sviluppo per il dispositivo nullo, funzionerà esattamente come il nodo /dev/null.

  1. In realtà ci sono due API di alto livello per "formattare il disco" in Windows: SHFormatDrive() e Win32_Volume.Format().

Ce ne sono due per un'API molto... beh... Finestre per una serie di motivi. Il primo chiede a Windows Explorer di visualizzare la normale finestra di dialogo "Formattazione disco", il che significa che funziona su qualsiasi versione moderna di Windows, ma solo quando l'utente è connesso in modo interattivo. L'altro può essere richiamato in background senza l'intervento dell'utente, ma non è stato aggiunto a Windows fino a Windows Server 2003. Esatto, il comportamento del sistema operativo principale è stato nascosto dietro un'interfaccia grafica fino al 2003, in un mondo in cui Unix ha spedito mkfs dal primo giorno.

La mia copia di Unix V5 del 1974 include /etc/mkfs, un eseguibile PDP-11 da 4136 byte collegato staticamente. (Unix non ha ottenuto il collegamento dinamico fino alla fine degli anni '80, quindi non è che ci sia una grande libreria da qualche altra parte a fare tutto il lavoro vero). Il suo codice sorgente, incluso nell'immagine di sistema V5 come /usr/source/s2/mkfs.c - è un programma C di 457 righe completamente autonomo. Non ci sono nemmeno #include dichiarazioni!

Questo significa che non solo si può esaminare ciò che mkfs ad alto livello, ma anche sperimentarlo usando lo stesso set di strumenti con cui è stato creato Unix, proprio come Ken Thompson, quattro decenni fa. Provate a farlo con Windows. La cosa più simile che si può fare oggi è scaricare il codice sorgente del DOS, rilasciato per la prima volta in 2014 che si riduce a un mucchio di sorgenti di assemblaggio. Si costruirà solo con strumenti obsoleti che probabilmente non avrete a portata di mano, e alla fine otterrete la vostra copia personale del DOS 2.0, un sistema operativo molto meno potente di Unix V5 del 1974, nonostante sia stato rilasciato quasi un decennio dopo.

(Perché parlare di Unix V5? Perché è il primo sistema Unix completo ancora disponibile. Le versioni precedenti sono apparentemente perdute nel tempo. C'è stato un progetto che ha messo insieme un Unix dell'era V1/V2, ma sembra essere scomparso. mkfs, nonostante l'esistenza della pagina di manuale della V1, linkata sopra, dimostri che deve essere esistito da qualche parte, in qualche momento. O chi ha messo insieme questo progetto non è riuscito a trovare una copia esistente di mkfs da includere, oppure sono io che faccio schifo a trovare file senza find(1)che non esiste in quel sistema. :))

Ora, potreste pensare: "Non posso chiamare semplicemente format.com? Non è forse la stessa cosa, in Windows, che chiamare mkfs su Unix?". Ahimè, no, non è la stessa cosa, per una serie di ragioni:

- 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. Quando parlo di dispositivi ad anello, parlo solo di Linux piuttosto che di Unix in generale, perché i dispositivi ad anello non sono portabili tra i sistemi di tipo Unix. Esistono meccanismi simili in OS X, BSD, ecc. ma la sintassi varia un po'.

  2. Ai tempi in cui le unità disco erano grandi come lavatrici e costavano più dell'auto di lusso del capo dipartimento, i grandi laboratori di computer condividevano una proporzione maggiore dello spazio collettivo su disco rispetto agli ambienti informatici moderni. La possibilità di innestare in modo trasparente un disco remoto nel filesystem locale ha reso questi sistemi distribuiti molto più facili da usare. È qui che si trova /usr/share, ad esempio.

Al contrario di Windows, dove un disco remoto è tipicamente mappato su una lettera di unità o deve essere raggiunto attraverso un percorso UNC, piuttosto che integrato in modo trasparente nel filesystem locale. Le lettere di unità offrono poche scelte per le espressioni simboliche; fa P: si riferisce allo spazio "pubblico" su BigServer o alla directory "packages" sul server mirror del software? I percorsi UNC implicano la necessità di ricordare su quale server si trovano i file remoti, il che diventa difficile in una grande organizzazione con centinaia o migliaia di file server.

Windows non ha avuto i collegamenti simbolici fino a Windows Vista, rilasciato nel 2007, che ha introdotto i collegamenti simbolici NTFS. I collegamenti simbolici di Windows sono un po' più potenti dei collegamenti simbolici di Unix - una caratteristica di Unix fin dal 1977 - in quanto possono puntare anche a una condivisione di file remota, non solo a un percorso locale. Unix lo ha fatto in modo diverso, tramite NFS nel 1984, che si basa sulla funzione di punto di montaggio preesistente di Unix, che ha avuto fin dall'inizio.

Quindi, a seconda di come la si guardi, Windows è in ritardo rispetto a Unix di circa 2 o 3 decenni.

Anche allora, i collegamenti simbolici non sono una parte normale dell'esperienza di un utente Windows, per un paio di motivi.

In primo luogo, è possibile crearli solo con il programma a riga di comando arretrato MKLINK. Non è possibile crearli da Esplora risorse, mentre gli equivalenti Unix di Esplora risorse sono tipicamente fanno permettono di creare collegamenti simbolici.

In secondo luogo, la configurazione predefinita di Windows impedisce agli utenti normali di creare collegamenti simbolici, richiedendo di eseguire la shell di comando come amministratore o di dare all'utente il permesso di crearli attraverso un percorso oscuro in uno strumento che l'utente medio non ha mai visto, tanto meno sa come usare. (E a differenza della maggior parte dei problemi legati ai privilegi di amministratore in Windows, l'UAC non è di alcun aiuto in questo caso).

  1. I sistemi Linux non usano sempre un'immagine di disco virtuale nella sequenza di avvio. Ci sono diversi modi per farlo.

  2. man ed

  3. I descrittori dei socket di rete sono FD anche sotto, comunque.

Puoi aggiungere valore alle nostre informazioni partecipando con la tua esperienza alle note.



Utilizzate il nostro motore di ricerca

Ricerca
Generic filters

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.