Credo che la risposta stia nel modo in cui definisci "Unix-like". Secondo la voce di wikipedia per "Unix-like", non sembra esserci una definizione standard.1
Un sistema operativo simile a Unix (a volte indicato come UN*X o *nix) è un sistema che si comporta in modo simile a un sistema Unix, pur non essendo necessariamente conforme o certificato a nessuna versione della Single UNIX Specification.
Non esiste uno standard per la definizione del termine, ed è possibile qualche differenza di opinione sul grado in cui un dato sistema operativo è "Unix-like".
Il termine può includere sistemi operativi liberi e open-source ispirati a Unix di Bell Labs o progettati per emularne le funzionalità, simili a quelli commerciali e proprietari e persino versioni basate sul codice sorgente UNIX concesso in licenza (che può essere sufficientemente "Unix-like" per superare la certificazione e portano il marchio "UNIX").
Probabilmente la ragione più ovvia è che UNIX e MINIX sono antecedenti a Linux, avendo ispirato la sua creazione.2
Torvalds ha iniziato lo sviluppo del kernel Linux su MINIX e le applicazioni scritte per MINIX sono state utilizzate anche su Linux. Successivamente, Linux è maturato e l'ulteriore sviluppo del kernel Linux ha avuto luogo su sistemi Linux.
Linus Torvalds aveva voluto chiamare la sua invenzione Freax, una combinazione di "free", "freak" e "x" (come allusione a Unix).
Se un sistema è monolitico o microkernel non sembra essere considerato quando si chiama un sistema operativo "Unix-like". Almeno, non tanto spesso quanto se il sistema è conforme a POSIX o prevalentemente conforme a POSIX.
Il "modo UNIX" si riferisce realmente all'esperienza dell'utente. È possibile combinare un piccolo insieme di utilità per creare un'efficace riga di comando del sistema operativo. In relazione a questo, le utilità dei sistemi operativi non sono in alcun modo "speciali" o hanno potere al di là dei programmi che puoi scrivere tu stesso.
Questo è un punto difficile da sottolineare in questi giorni, dal momento che UNIX ha avuto un tale successo in questo aspetto che è diventato il modo in cui i sistemi operativi dovrebbero presentare le loro interfacce a riga di comando. Il punto è meglio illustrato da un controesempio:ecco come fare cp a.txt b.txt su un mainframe IBM:
//COPY JOB ,CLASS=E,MSGCLASS=X,NOTIFY=&SYSUID
//cp EXEC PGM=IEBGENER
//SYSIN DD DUMMY
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSNAME=a.txt,DISP=SHR
//SYSUT2 DD DSNAME=b.txt,DISP=(NEW,CATLG),UNIT=SYSDA
Questo non copierà nemmeno ogni tipo di file.
UNIX ha formulato una serie di presupposti che semplificano l'usabilità a discapito delle prestazioni. I canali file 1 (stdin), 2 (stdout) e 3 (stderr) vanno da e verso il terminale, rimuovendo gran parte del boilerplate dal JCL sopra. Il filesystem supporta un tipo di dati - byte - e una modalità di accesso - sequenziale (sebbene il puntatore in cui i dati sequenziali possono essere letti o scritti possa essere spostato per implementare una sorta di "accesso casuale"). Ciò significa che le utilità di sistema devono gestire solo un tipo di file e un tipo di dati per coprire tutti i file ei tipi di dati. Il filesystem non richiede la preallocazione. L'aggiunta di file alla directory (nota anche come "catalogo del disco" sui mainframe IBM) avviene automaticamente se il nome del file è noto al sistema operativo.
Queste ipotesi hanno avuto un tale successo che in questi giorni non ci pensiamo nemmeno due volte. Considerando che all'epoca sarebbero apparsi dissoluti -- immagina il semplice sovraccarico di un filesystem a cui non era stata comunicata in anticipo la dimensione massima di un file.
Ma UNIX non si è fermato qui. Ha promosso un approccio "cassetta degli attrezzi" alle utilità di sistema. IEBGENER del mainframe può stampare file, riorganizzare campi all'interno di record, eliminare record, creare record vuoti. Al contrario, in UNIX cp copia i file, cat elenca i contenuti dei file, cut gestisce i campi. C'è una sintassi ordinata per mettere in stringa lo stdout di un comando allo stdin del file successivo, tutto su una riga di terminale. Usando questa sintassi "pipe" e quei piccoli comandi possiamo fare tutto ciò che può fare IEBGENER. E cose che gli autori di IEBGENER non si sarebbero mai sognati.
Kernighan e Plauger hanno scritto un libro influente nel 1976 su questo approccio:Strumenti software - e questa è davvero la prima esposizione del "modo UNIX". Kernighan e Pike hanno ribadito questo approccio nel loro libro del 1984 The UNIX programming environment .