Newsgroup: it.comp.os.dibattiti
Titolo: Apple, ma che è successo?

Guardando le statistiche di Secunia:
APPLE MACINTOSH OS 9
Vendor  	 Apple
Product Link 	View Here (Link to external site)
Affected By 	1 Secunia advisories
Unpatched 	0% (0 of 1 Secunia advisories)
Most Critical Unpatched
There are no unpatched Secunia advisories affecting this product, when
all vendor patches are applied.
APPLE MACINTOSH OSX
Vendor  	 Apple
Product Link 	View Here (Link to external site)
Affected By 	98 Secunia advisories
Unpatched 	19% (19 of 98 Secunia advisories)
Most Critical Unpatched
The most severe unpatched Secunia advisory affecting Apple Macintosh
OS X, with all vendor patches applied, is rated Highly critical
-------------------
E' straordinario vedere come gli advisory siano passati da 1 a 98!!!!!

 E' straordinario vedere come gli advisory siano passati da 1 a 98!!!!!
non e' successo niente: e' un sistema desktop come gli altri.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

Giulio Severini wrote:
:: E' straordinario vedere come gli advisory siano passati da 1 a
:: 98!!!!!
Semplicemente sono passati da un OS giocattolo al livello di Windows 3.1 ad 
uno vero.
Saluti.
 

 E' straordinario vedere come gli advisory siano passati da 1 a 98!!!!!
Tu dovresti imparare a interpretare i numeri. Per esempio in MacOS 9 hanno
trovato una vulnerabilità dal 2003 al 2007.
Peccato che MacOS 9 è 'morto' dal 2001. Come dire... non vuole dire un
accidenti. 
Se poi confronti con i concorrenti, scopri che sono un numero
sorprendentemente basso (senza considerare che i vari concorrenti hanno le
vulnerabilità separate per versione, mentre quelle di MacOS X sono messe
tutte insieme).
Di queste ce ne è una rognosa con UFS (che è de-facto deprecato), un'altro
è in effetti un baco di ftpd.

 uno vero.
Motiva: MacOS 'classico' era ed è sempre stato nettamente più avanzato di
Windows 3.x. Windows ha fatto il 'gran passo' con il 2k, ma anche li è
stato raggiunto abbastanza alla svelta.

 Windows 3.x.
Per qualcuno il multitasking cooperativo non e' buono: quello preemprive
e' il multitasking figo... Insomma l'homo sapiens vuole la
prevaricazione
anche a livello di S.O. :-)
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Per qualcuno il multitasking cooperativo non e' buono
Come minimo per tutti i possessori di CPU con piů di sedici bit, una MMU e
qualche MB di RAM.
-- 
emboliaschizoide.splinder.com

 qualche MB di RAM.
Parlando seriamente, la tua e' una cazzata. Il multitasking
preemptive e' (o puo' essere) cosa "buona e giusta", per sistemi
operativi che hanno un utente attaccato alla tastiera (sistemi
interattivi). Per eseguire compiti di calcolo intensivo sono una 
tragedia a causa dei context switch programmati, spesso necessari
solo per eseguire lo schedulatore.
Per alcuni tipi di task, il multitasking di tipo cooperativo e'
decisamente meigliore di quello premptive: il processo attivo ha
tutta la macchina per se per tutto il tempo che gli occorre e la
lascia solo quando gli sarebbe inutile tenerla (es attesa di input
da una periferica lenta).
Niente sprechi associati a context switch inutili ai fini di quello
che e' realmente il compito da eseguire.
Il multitasking di tipo cooperativo NON e' piu' scadente di quello
preemptive, e' solo piu' complicato da programmare ed adatto a
compiti di tipo "batch": non c'entra niente con MMU, CPU a 16 bit
e Kg di RAM disponibile.


Enrico Franchi wrote:

MacOS classico l'unica cosa buona che aveva era che era Apple, ovvero figo e 
trendy glamour.
Il limite, te lo hanno spiegato, è il modello cooperative. Semplicemente non 
idoneo per un OS desktop del 2000. Figuriamoci per un OS server.
Saluti.

 e Kg di RAM disponibile.
Tutto buono tranne qua. Il multitasking pre-emptive e` IMPOSSIBILE da
programmare. Sono 50 anni che ci si prova e NESSUNO ci e` ancora
riuscito, ogni anno arriva la nuova ideona e 2 mesi dopo che la si usa
in un progetto di medie-grosse dimensioni si inizia a preferire
l'inferno.
Riportiamo un po` di linkuzzi:
http://patricklogan.blogspot.com/2007/02/misguided-road-not-to-be-travel
led.html
http://weblogs.mozillazine.org/roadmap/archives/2007/02/threads_suck.htm
l
http://weblogs.mozillazine.org/roc/archives/2006/12/parallelism_1.html
http://steve.yegge.googlepages.com/ten-predictions
 (numero 3)
http://www.computer.org/portal/site/computer/menuitem.5d61c1d591162e4b0e
f1bd108bcd45f3/index.jsp?&pName=computer_level1_article&TheCat=1005&path
=computer/homepage/0506&file=cover.xml&xsl=article.xsl
E potrei continuare per lungo lungo lungo lungo lungo tempo ancora.
-- 
Valentino Volonghi aka Dialtone
Blog: 
http://www.twisted.it/
Wii Code: 3069 7621 2175 6539
Friend Codes: 
http://www.consolerecords.it/forum/viewtopic.php?t=217

 idoneo per un OS desktop del 2000. Figuriamoci per un OS server.
Perché, il Mac 'Classico' era un sistema operativo da server?
In compenso, per l'uso individuale aveva un eccellente sistema di
gestione dei font, del colore e del PostScript (delizia per chi faceva
publishing), ed un'ottima, per l'epoca, gestione dei flussi audio
(delizia per i musicisti).
Sistema ormai superato, ma difficilmente definibile 'giocattolo'. A meno
che con il computer si faccia altro piuttosto che lavorare, e si
preferisca usarlo per giocare a chi spara i paroloni piů grossi...
Ciao,
Paolo

 Figuriamoci per un OS server.
Cosa c'entrano i server con MacOS classico???
Dovervi per forza aprire bocca per parlar male senza motivo?
(come fa di solito BARRYZ...)

 decisamente meigliore di quello premptive
Sě, durante il caricamento di un gioco del C64 attraverso il registratore č
bene ridurre al minimo i malvagi context switch, in effetti.
-- 
emboliaschizoide.splinder.com

 Riportiamo un po` di linkuzzi:
Ma qui si parla di programmazione _multi-threading_, che dipende dal
linguaggio adottato, non dal multitasking preemptive del SO.
O mi sfugge qualcosa?
Voglio dire, i linguaggi con VM possono benissimo lasciare i dettagli
della creazione/distruzione/sincronizzazione dei thread alla VM stessa.

 della creazione/distruzione/sincronizzazione dei thread alla VM stessa.
Non e` affatto vero. E guarda caso non esistono linguaggi che lo fanno
:). Il problema di multi-tasking pre-emptive e multi-threading e` sempre
lo stesso identico, da qui i vari problemi di locking interno al kernel
ecc ecc.
I link che ho riportato sono piu` che esaurienti riguardo all'argomento
per cui non vedo perche` non leggerli tutti con attenzione. Addirittura
per questi problemi e` stato creato dragonfly bsd e mi sembra abbastanza
come dimostrazione che il problema e` affine sia a livello di OS che a
livello di utente, anche se a livello OS ha un po` piu` senso usare i
thread.


 per cui non vedo perche` non leggerli tutti con attenzione.
L'ho letti, si parla dei problemi del multi-threading, che sono noti
e sui quali siamo tutti d'accordo :)
Quello che voglio dire č che se ci sono problemi con il multi-thrading si
possono risolvere in userspace.
Da 
http://weblogs.mozillazine.org/roadmap/archives/2007/02/threads_suck.html
"There are better ways. Clueful hackers keep rediscovering Erlang"
Usiamo Erlang!
Esempio personale: qualche tempo fa ho usato Twisted per un progetto e devo
dire che mi sono trovato benissimo :)
Insomma, questi problemi dal mio punto di vista (e non solo mio) sono risolvibili
a patto di alzare un po' il livello di astrazione, ma il SO (il kernel) puň
continuare ad adottare un multitasking preemtive nudo e crudo perché č il piů
efficiente per la gestione delle risorse a livello globale.
Infatti l'ultimo link che hai postato finisce con:
"They [i threads] must be relegated to the engine room of computing,
to be suffered only by expert technology providers."
(io "engine room of computing" l'ho inteso come il kernel, ma potrei sbagliami..)

Paolo Tramannoni wrote:
:: Perché, il Mac 'Classico' era un sistema operativo da server?
Per fortuna no.
:
:: In compenso, per l'uso individuale aveva un eccellente sistema di
:: gestione dei font, del colore e del PostScript (delizia per chi
:: faceva publishing), ed un'ottima, per l'epoca, gestione dei flussi
:: audio (delizia per i musicisti).
Questo è innegabile.
:: Sistema ormai superato, ma difficilmente definibile 'giocattolo'. A
:: meno che con il computer si faccia altro piuttosto che lavorare, e si
:: preferisca usarlo per giocare a chi spara i paroloni più grossi...
Eh, si.

 ..)
E` chiaro che non si puo` essere d'accordo con tutto ma lo si puo`
essere in linea generale. Io penso che anche li` i thread non scalino
affatto (infatti oltre un certo numero di processori le prestazioni
smettono di salire. Quindi anche li` deve esserci un modo migliore di
sfruttare le risorse.


 l'inferno.
Ieri ho dato un'occhiata in giro, e sinceramente ho paura che tu abbia
scantonato il problema.
La difficolta' di programmazione e' tipica di qualunque sistema
multitasking. Il multitasking preemptive e' decisamente piu' semplice
da programmare di quello cooperative: semplicemnte ignori che esista,
quando e' ora di un context switch e' una affare del  S.O. e tu
nemmeno
ti accorgi che e' avvenuto.
I link che hai dato tu riguardano i thread, e li hai perfettamente
ragione: programmare con i thread e' un bordello elevato al cubo.
Ma questo e' indipendente dal tipo di multitasking che hai sotto.
C:\>iao Angelo

 bene ridurre al minimo i malvagi context switch, in effetti.
Che dire... Con una simile argomentazione, non posso che inchinarmi
alla sapienza pura.
C:\>iao Angelo

 idoneo per un OS desktop del 2000. Figuriamoci per un OS server.
In primo luogo MacOS 8/9 non è stato venduto come OS server. Semplicemente
non era adatto. Anche se posso dirti che lo ho visto usare *anche* come
server. Sorprendentemente, se la cavava decentemente (a patto di stare in
una intranet).
Detto questo, non puoi separare OS giocattolo o non giocattolo in base al
tipo di multitasking. Voglio dire ce lo ricordiamo che con Windows 98 se
cambiavi i parametri di rete dovevi riavviare? Io questo si che lo chiamo
un OS giocattolo.
E nota che io non sono uno di quelli che difendono a spada tratta il
vecchio MacOS. Ai tempi di MacOS 8.6, io ho abbandonato e sono 'passato' a
GNU/Linux, proprio perchè l'OS era insufficiente per le *mie* esigenze (fra
certe API demenziali, altre mancanze e tutto...).
D'altra parte da usare era molto piacevole, e si lavorava bene. Tutt'ora
Windows non ha un sistema di gestione del colore che possa essere
confrontata con quella che MacOS aveva dieci anni fa. Per dire. 
E il vecchio MacOS, nonostante le sue magagne, funzionava egregiamente
perfino in campo audio, per capirci. Certo, non era un sistema server.
Aveva i suoi problemi.
Ma era tutto fuorchè giocattolo. E complessivamente funzionava molto meglio
dei concorrenti. 
Come ti ho detto il grande passo Windows lo ha fatto con 2K. NT era ben
fatto, ma aveva una diffusione sui desktop quasi nulla (oltre che, IIRC,
alcune differenze con il 98 per cui non tutto quello che girava su uno
girava sull'altro... forse qualcosa con le direct x, ma sparo nel mucchio,
saprai sicuramente meglio di me quale era il problema -- e ribadisco, la
memoria qua mi sta tradendo --)

 prevaricazione anche a livello di S.O. :-)
Beh, oggettivamente su un sistema desktop è comoda come cosa eh...