Mac o PC?
Domanda semplice e secca: dovendo scegliere tra un Mac e un PC, quale scegliereste? e perché? Qual è meglio?
Ovviamente, se volete, potete anche paragonare prodotto per prodotto: MacBook Pro vs PC, Mac Pro vs PC, iMac vs PC, Mac Mini vs PC, Mac Book vs PC ...
P.S.
Non devo prendere né l'uno né l'altro: curiosità.
Ovviamente, se volete, potete anche paragonare prodotto per prodotto: MacBook Pro vs PC, Mac Pro vs PC, iMac vs PC, Mac Mini vs PC, Mac Book vs PC ...
P.S.
Non devo prendere né l'uno né l'altro: curiosità.
Risposte
Nei sistemi UNIX tipo BSD e in Linux il software viene compilato da sorgente ed eventualmente pacchettizzato. In questo modo, ad esempio, tutti i programmi che necessitano della libreria libblas.so vengono tutti linkati ad una unica versione di questa libreria, che viene installata direttamente nel LDPATH del sistema. In questo modo si necessita di un'unica libreria BLAS, uguale per tutti. Questo presuppone però che il distributore (Debian,Ubuntu o FreeBSD) abbia a disposizione il codice sorgente in modo da poterlo compilare con le giuste librerie ed eventualmente si può pensare a patcharlo qualora il codice non funzioni con la versione della libreria distribuita...
Ovviamente questo è inconcepibile per software closed-source che arriva già compilato e linkato a specifiche versioni delle varie librerie senza la possibilità, in generale, di modificare le librerie cui questo è linkato. In particolare il software closed-source sarà linkato dinamicamente a tutta una serie di librerie di sistema "standard" che si presuppone siano già installate nel sistema (tipo le glibc) e che non vengono distribuite insieme al software e poi sarà linkato a tutta una serie di altre librerie, sia opensource che non, che vengono distribuite insieme al software in questione. Il problema è quindi gestire tutte queste librerie in più che spesso conflittano con le librerie di sistema (nel senso che vengono distribuite versioni differenti di librerie già presenti...). Linux, OSX e Windows hanno risolto il problema in 3 modi diversi:
- Linux : i software closed source vengono tutti installati in /opt e niente viene mai linkato con librerie provenienti da questi software, in modo da evitare problemi. Dopodiché eventualmente si aggiungono al PATH le cartelle in /opt. La posizione delle librerie dei programmi closed source sono, credo, hard-coded dentro il codice, con path relativi, dopodiché ld farà il suo buon lavoro a prendere per "acroread" le librerie cui questo è associato. La soluzione Linux è la più semplice, ma probabilmente anche la meno efficace dato che la parte delle librerie "standard" di sistema è molto piccola e spesso distribuzioni diverse hanno versioni incompatibili di alcune librerie base. C'è anche un progetto noto come Linux Standard Base che si prefigge come obbiettivo quello di stabilire un set di librerie cui un produttore software possa fare sempre e comunque riferimento sviluppando codice chiuso per Linux.
- OSX : la soluzione .app è molto simile a quella /opt, anche se il PATH degli eseguibili non viene esportato e i programmi sono un po' più isolati fra di loro. Le librerie audio e video di riferimento per OSX sono certamente molto complete e c'è il vantaggio, per i produttori software, di non avere alcuna ambiguità riguardo alle librerie pre-installate, dato che OS-X è uno per tutti e non vi sono distributori diversi che operano scelte differenti.
- Windows : la soluzione è quella famosa del registro di sistema: vengono registrati tutti gli eseguibili e le librerie a cui linkano in modo che il linker dinamico faccia il suo lavoro. Probabilmente questa è la soluzione più efficace fra le 3 previste e non a caso Windows è diventata la piattaforma per eccellenza su cui sviluppare software closed source. Le librerie native di windows poi sono sconfinate, anche se piene di schifezze rimaste addirittura dai tempi del 16bit... Quella di windows però è anche la soluzione più complicata e come tutte le cose più complicate spesso presenta dei problemi...
Nessuna delle tre soluzioni è ottimale perché tutte favoriscono il proliferare di copie delle stesse librerie. Forse quella windows è la più accettabile dato anche il modello di sviluppo dei codici che girano sotto windows...
L'ideale è chiaramente la soluzione UNIX-OSS che garantisce la possibilità di avere sistemi più leggeri e perfettamente ottimizzati...
PS : Ovviamente io sono di parte!
Ovviamente questo è inconcepibile per software closed-source che arriva già compilato e linkato a specifiche versioni delle varie librerie senza la possibilità, in generale, di modificare le librerie cui questo è linkato. In particolare il software closed-source sarà linkato dinamicamente a tutta una serie di librerie di sistema "standard" che si presuppone siano già installate nel sistema (tipo le glibc) e che non vengono distribuite insieme al software e poi sarà linkato a tutta una serie di altre librerie, sia opensource che non, che vengono distribuite insieme al software in questione. Il problema è quindi gestire tutte queste librerie in più che spesso conflittano con le librerie di sistema (nel senso che vengono distribuite versioni differenti di librerie già presenti...). Linux, OSX e Windows hanno risolto il problema in 3 modi diversi:
- Linux : i software closed source vengono tutti installati in /opt e niente viene mai linkato con librerie provenienti da questi software, in modo da evitare problemi. Dopodiché eventualmente si aggiungono al PATH le cartelle in /opt. La posizione delle librerie dei programmi closed source sono, credo, hard-coded dentro il codice, con path relativi, dopodiché ld farà il suo buon lavoro a prendere per "acroread" le librerie cui questo è associato. La soluzione Linux è la più semplice, ma probabilmente anche la meno efficace dato che la parte delle librerie "standard" di sistema è molto piccola e spesso distribuzioni diverse hanno versioni incompatibili di alcune librerie base. C'è anche un progetto noto come Linux Standard Base che si prefigge come obbiettivo quello di stabilire un set di librerie cui un produttore software possa fare sempre e comunque riferimento sviluppando codice chiuso per Linux.
- OSX : la soluzione .app è molto simile a quella /opt, anche se il PATH degli eseguibili non viene esportato e i programmi sono un po' più isolati fra di loro. Le librerie audio e video di riferimento per OSX sono certamente molto complete e c'è il vantaggio, per i produttori software, di non avere alcuna ambiguità riguardo alle librerie pre-installate, dato che OS-X è uno per tutti e non vi sono distributori diversi che operano scelte differenti.
- Windows : la soluzione è quella famosa del registro di sistema: vengono registrati tutti gli eseguibili e le librerie a cui linkano in modo che il linker dinamico faccia il suo lavoro. Probabilmente questa è la soluzione più efficace fra le 3 previste e non a caso Windows è diventata la piattaforma per eccellenza su cui sviluppare software closed source. Le librerie native di windows poi sono sconfinate, anche se piene di schifezze rimaste addirittura dai tempi del 16bit... Quella di windows però è anche la soluzione più complicata e come tutte le cose più complicate spesso presenta dei problemi...
Nessuna delle tre soluzioni è ottimale perché tutte favoriscono il proliferare di copie delle stesse librerie. Forse quella windows è la più accettabile dato anche il modello di sviluppo dei codici che girano sotto windows...
L'ideale è chiaramente la soluzione UNIX-OSS che garantisce la possibilità di avere sistemi più leggeri e perfettamente ottimizzati...
PS : Ovviamente io sono di parte!
Accedi a tutti gli appunti
Tutor AI: studia meglio e in meno tempo