Un articolo (serio) contro Un*x

[MazinKaesar]

Tutto sommato, in molte cose ha ragione...
http://www.informit.com/articles/articl ... 24451&rl=1

anche se io per un server mi fido esclusivamente di sistemi Unix

[RadomE]

Bah...molte affermazioni le trovo discutibili anche se ho letto di fretta, mi sembra uno di quei lamer che non hanno niente di meglio da fare che criticare senza conoscere effettivamente il perchè di alcune scelte architetturali.

[ncc-1700]

......mi sono fermato alla prima, quella che dice che un socket non è un file.?!?!?!
Le motivazioni che usa sono un pò infantili e si capisce che non è andato a fondo sul perchè ed il percome di certe cose. Non dico che UNIX sia il meglio del meglio, è vecchiotto e mostra tutti i suoi limiti, ma criticare così giusto per riempire le pagine di un sito WEB

Ciao,
ncc-1700

[riko]

Obiezione numero 1: 3,5 fortemente insufficiente. Tutti gli esempi che fa sul fatto che uno non possa scrivere dentro un file un immagine sono semplicemente assurdi. La stampante che non stampasse un immagine come stream raw non sarebbe di responsabilità di un sistema *nix.

Semplicemente le cose a basso livello *devono* essere stupide. Tutto è un file nel senso che il sistema per leggere e scrivere è lo stesso, poi quello che uno fa e deve fare con i dati è affar suo, non certo di altri.

Riguardo a X11 poi siamo ridicoli. Io sparo dentro un flusso di byte (che per me è un immagine, ma per il computer è solo un flusso di byte) l'X11 e lui me la dovrebbe mostrare? E dove? Al centro, in un angolo? Cosa?

La metafora è comoda e non porta *nessun* problema (diversamente dall'avere 28 syscall per ogni maledettissimo aggeggio). Poter scambiare tranquillamente files, pipes e compagnia a me sembra solo comodo.


Obiezione tutto è testo: 4
Il 4 è per avere azzeccato un problema. Effettivamente sui sistemi malconfigurati ci sono problemi con i locali (e anche su quelli ben configurati alle volte). Il problema è che un file di testo non specifica da nessuna parte la sua codifica, e un OS non ha modo di sapere quale sia l'encoding. Lo stesso problema lo ha windows, per dire. La soluzione è Unicode.
Ovviamente un peccato il delirio successivo.
Tutta la sua sega sul sortare ls si sarebbe risolta leggendo il manuale. Se non fosse stato perchè c'è un'opzione apposita per farlo gli avrei dato 5,5 per la buona volontà.
Tutt'ora mi chiedo quale sarebbe stata la sua soluzione. Se uno vuole una gui la ha anche sotto *nix. Se uno vuole qualcosa di più di ls ha mc. Se uno vuole buttare fuori il testo... cosa propone, una console orientata agli oggetti?

No Introspection: 7
Tutte buone idee, quasi nulla da dire. Tuttavia che io sappia nessun sistema offre quello che l'autore cerca. Gran parte del sw andrebbe riscritto, ma non so se tutto questo sarebbe davvero comodo.
Quello sulle opzioni localizzate poi è delirio. Costringerebbe comunque tutti a conoscere le opzioni in inglese (se si vuole leggere o modificare lo script) quindi non vedo vantaggi concreti.

X11: Voto 6
Allora che NeWS fosse migliore di X11 lo sanno anche i porci. NeWS aveva alcuni problemi noti però. Costava un botto ed era iperproprietatio.
Programmarlo era un macello (avete mai letto un sorgente post-script?) e per di più andava fatto metà nel linguaggio scelto per il backend e metà per il client in postscript.
Complessivamente era molto meglio DPS di NeXT e qualcosa di simile lo abbiamo con Quartz. Resta comunque il fatto che X11 non è malaccio, e consente di fare facilmente cose che altri non permettono.
Se uno poi non vuole vederlo, può tranquillamente ignorarlo e pensare esclusivamente a livello di QT (per dire).

stdin/stdout: Voto 1
Qui siamo sul ridicolo. La critica alle pipe è una scemenza. Le pipe servono per fare una cosa, e fanno quella. Se uno ha bisogno di cose più complesse le fa, con programmi apposti.

Vogliamo immaginarci una sintassi per quello che suggerisce l'autore?

demultiplex filevideo.mov >&1 >&2 >&3 >&1 convert_divx >&2 >&3 conv_mp3

Suvvia... chi userebbe una cosa del genere? L'esempio principe che fa (lavorare con il multimedia) è uno degli esempi principe in cui le GUI eccellono.

Synchronous System Calls: Voto 4
Ok. Fare le cose asincrone è bello. Ma questo ha poco a che fare con "unix". Il modello portato ad esempio è QNX. QNX, il sistema che si è chiamato anche qunix prima di cambiare per ragioni di copyright. Il sistema che a metà degli anni 90 era completamente POSIX compatibile e che, udite udite nel 2001 è stato rimodellato per assomigliare a Linux.

Poi di sistemi *nix a microkernel piuttosto che altro ce ne sono stati altri. La faccenda delle syscall è in effetti un non-problema. Il context-switch può venire minimizzato come costo (attraverso buffering e compagnia), e d'altra parte le alternative sono poche

1) microkernel: a questo punto le syscall non fanno context-switch perchè sono quasi tutte in user-space
2) mettiamo tutto in kernel-space.

Ora quasi tutti i microkernel "completi" sono falliti proprio per ragioni prestazionali. La comunicazione fra i vari serventi era troppo costosa. Perfino MacOS X che mantiene la *struttura* del microkernel, alla fine tiene comunque tutto in kspace, idem Windows. In pratica qnx è quasi un unicum... e comunque viene da chiedersi se effettivamente non è che qnx è un sistema differente e con diversi obiettivi rispetto un sistema desktop puro.

One-Way system calls: Voto 3
a questo punto non si capisce. Parla di Unix(tm) [ che non lo usa più nessuno o quasi ] o parla di unix in senso generico?
Perchè indica come "problema" uno che alcuni sistemi unix generici non hanno.
E chi cita? Hurd e Mach. Hurd che sono almeno 15 anni che ci lavorano senza quasi cavare un ragno da un buco (adesso stanno combinando qualcosa, hanno buttato via qualcosa e sono ripartiti da 0) e Mach. Mach che è bello finchè volete, ma i maggiori sistemi odierni in qualche modo basati su Mach (Windows NT/XP e MacOS X) hanno scelto di sparare di nuovo tutto in Kernel space.
Ovvero anche se quello che l'autore propone sarebbe carino in teoria, si è dimostrato irrealizzabile in pratica.

Critica al C: Voto 4
Io sul C sono sempre stato critico. I problemi descritti esistono. Ma siamo sicuri che siano davvero problemi? Dopo tutto quasi tutti i sistemi odierni a basso livello sono basati sul C.
*Adesso* sta venendo fuori C# in ambito MS.

Se uno vuole programmare unix in una ltro linguaggio di programmazione, può farlo e non si perde nulla. Non vedo il problema. D'altra parte un linguaggio piccolo e veloce è assolutamente comodo in molti casi.

Nomina Smalltalk. Bellissimo linguaggio, davvero. Molte delle sue caratteristiche le adoro in ObjectiveC e Python (i miei favoriti, in effetti).
Smalltalk per certe cose è anche molto più avanti. Peccato che ha un paradigma di programmazione abbastanza tipico, e che 9 persone su 10 impazzirebbero solo a pensarci (tipo mancano le strutture di controllo come parte del linguaggio).
In questo senso Smalltalk offre una delle migliori implementazioni del paradigma ad oggetti.
Peccato che Smalltalk abbia un problema. È a livello veramente alto. Ci sono studi che hanno dimostrato che per molti compiti dentro un kernel, perfino il C++ sarebbe eccessivamente pesante, e che alla fine l'alternativa è C o assembler.

Poi personalmente non scaricherei le "colpe" del C su *nix. C mi sembra anzi indicatissimo per lavorare a basso livello (come mi aspetto da qualcocsa che è a basso livello).

Poi gli applicativi soprastanti li scriverò in Python, Ruby, Java, Perl, ObjectiveC, C# al limite C++...

Small Tools, Not Small Libraries: Voto 1
Non si capisce nemmeno cosa vuole dire. Nomina le librerie una volta e basta... dopodichè dimentica che la maggior parte dei sistemi unix sono estremamente efficienti a essere caricati e scaricati (e proprio perchè sono scritti in C, pensa te).
Nessuno vieta di fare sistemi più grossi, per inciso.

Resta il fatto che il paradigma divide et impera è pervasivo in tutta l'informatica (dividere un problema in piccole cose e farle al meglio per ottenere un risultato più facilmente).

Non solo. Anche oggi si tende quanto più possibile alla programmazione distribuita. Ovvero smembrare le cose in quanti più componenti abbia senso, ciascuno con il suo uso (e la possibilità di essere riutilizzato) e poi farli parlare fra loro.

In-Band Signaling as Standard: Voto 5
L'istanza è giusta (anche se si è scordato che MacOS X, un sistema unix è il sistema principe con i metadati al momento...). Ma infila in giro un sacco di deliri.
DOS, che usava l'estensione di un file di tre lettere per capire cosa fosse un file sostiene che non usasse il *nome* del file. Io direi che ne usava l'ultima parte.
Nota che anche la maggior parte dei sistemi unix adesso usano anche le estensioni, assieme (quando più possibile) ai magic number. Sistema parecchio furbo.
Per esempio possiamo intuire che un file che inizia con <html> è in effetti un file di testo, o no? Ma vabbè.

Conclusione: Voto 2, 5
Non dice *nulla*. Parla di "moderni sistemi operativi", ma non dice quali sono. Il primo che mi viene in mente, MacOS X, che da solo negli ultimi anni ha innovato (o per lo meno preso le migliori caratteristiche già implementate e le ha fuse) usa come base proprio unix... la cosa buffa è che è uno sviluppatore su MacOS X con all'attivo guide e saggi su GNU/Linux.

Media: 4
Direi che è un articolo mal fatto. Grosso modo dice di criticare *nix, ma quando ci prende, critica un po' tutto il mondo. Quando non ci prende poi, non ci prende. Strano, la persona sembra competente leggendo in rete. Immagino che avesse bisogno di un poco di pubblicità.

[MazinKaesar]

Media: 4
Direi che è un articolo mal fatto. Grosso modo dice di criticare *nix, ma quando ci prende, critica un po' tutto il mondo. Quando non ci prende poi, non ci prende. Strano, la persona sembra competente leggendo in rete. Immagino che avesse bisogno di un poco di pubblicità.

[MazinKaesar]

A volte ritornano...

http://www.informit.com/articles/articl ... 56824&rl=1