Newsgroup: it.comp.os.dibattiti
Titolo: Sistemi Operativi

Alcuni qui dicono che un OS è una cosa che deve solo dialogare con l'HW, 
e se ne deve fregare dell'utente.
Qualcuno non è d'accordo, e questo qualcuno è Debian:
Cos'è Debian?
Debian è un sistema operativo (OS) libero (free) per il tuo computer. Un 
sistema operativo è l'insieme dei programmi di base ed utilità che fanno 
funzionare il tuo computer. Debian utilizza Linux come kernel (la parte 
centrale di un sistema operativo), ma molti dei programmi di utilità 
vengono dal GNU project; per questo usiamo il nome GNU/Linux.
Dunque Debian è l'OS, e linux è il kernel. Il kernel dialoga con l'HW, 
Debian si occupa del resto, interazione con l'utente inclusa, e mi pare 
che Debian contenga anche browsers, gui, e quant'altro.
Solo uno spunto di riflessione per tipi come Salzano.
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
                                       Bertrand Russell
                                       The Philosophy of Logical Atomism

che Debian contenga anche browsers, gui, e quant'altro.
La definizione che mi hanno sempre insegnato di SO si può
riassumere in: set minimale di applicazioni per il
funzionamento dell'hw sottostante.
Ovviamente bisogna determinare cosa si intende per
"minimale"...una shell potrebbe esserlo ma un browser di
sicuro no
--
Lawrence Oluyede
rhy...@myself.com

Lawrence Oluyede wrote:

Debian contiene ben più di una shell testuale, ed è definita un Sistema 
Operativo da chi Debian la fa.
Ed io sono d'accordo, ben inteso.


 sicuro no
Per windows invece è ultra necessario un browse, altrimenti come 
scarichi le patch e service pack :-) ?
ciao
-- 
Per rispondere togliere "1975" dall'indirizzo
To Reply remove "1975"
-------------------------------------------

 Solo uno spunto di riflessione per tipi come Salzano.
Non so nulla della tua disputa con Salzano, ma hai omesso qualcosa dal
testo presente sulla home page di Debian:
'Debian GNU/Linux fornisce pių di un semplice OS: viene distribuito con 
oltre 3950 pacchetti, programmi giā compilati e impacchettati in in modo 
tale da permettere installazioni facili sulla tua macchina'.
Quindi come si puo` facilmete leggere Debian *non* dice che 'browser, gui
e quant'altro' debbano far parte del 'semplice OS' essendo Debian piu` di
un 'semplice OS'.
-- 
Vincenzo 
Le donne non sanno di essere sedute sulla loro fortuna.

 un 'semplice OS'.
E' un "complicato OS"? Per me va bene, ma sempre OS rimane.


 Dunque Debian č l'OS, e linux č il kernel.
Stai travisando. Un qualsiasi browser distribuito con una debian puo' o
meno essere installato, puo' benissimo esser cestinato in favore di un
altro, sempre distribuito con debian o preso altrove.
Come vedi debian non porta uno specifico browser ad avere un ruolo
particolare nel sistema. Non mi pare sia comparabile con quanto fa MS a
proposito di Explorer.
-- 
):E...

 E' un "complicato OS"? Per me va bene, ma sempre OS rimane.
Logica a buon mercato? Si, ma di scarsa qualita'!
-- 
):E...

 
Cvd.
-- 
Renato "Hitman" Salzano / Mexico86 Fan | e-posta:  sonicblast(at)
inwind.it
IHGGer #778 / NapolICErs # 2           | 
http://spazioweb.inwind.it/hitman
GdGnocca #6 / Bassista dei "2ofSpades" | ICQ #75729987 
"Dio dell'ovvietà / qual'è la faccia mia / per questa gente nella via?"

 Debian è una distro, l'OS è linux.
Diglielo a quelli di debian, pare che non lo sappiano.


 Diglielo a quelli di debian, pare che non lo sappiano.
Edddai, ti appendi a tutti i cavilli!
-- 
):E...

 Edddai, ti appendi a tutti i cavilli!
Cavilli? Mi pare più che evidente che quelli di Debian definiscono 
Debian l'OS e linux il kernel: sta scritto nella loro pagina...
Cmq, pensatela come volete... io resto delle mie idee.


 Cmq, pensatela come volete... io resto delle mie idee.
Su questo non c'e' dubbio. E' evidente che non sei qui' per metterle in
discussione ragionevolmente.
-- 
):E...

 Debian l'OS e linux il kernel: sta scritto nella loro pagina...
da 
www.debian.org
Debian GNU/Linux provides more than a pure OS: it comes with more than
3950 packages, precompiled software bundled up in a nice format for easy
installation on your machine.
I casi sono due: o non sai l'inglese oppure sei in malafede.

 discussione ragionevolmente.
Ma perché, tu ragioni? A me pare che tu sia soltanto capace di darmi 
torto senza portare argomentazioni valide a suffragio delle tue tesi.


 I casi sono due: o non sai l'inglese oppure sei in malafede.
No, il caso è uno solo: dovresti accendere il cervello prima di scrivere 
qualcosa.


 contraddizione:
Questo significa solo che non e` intenzione della home page di Debian
di scendere nel dettaglio nella definizione di os.
Dovresti comprendere che quando si scrive un testo destinato ad un
pubblico molto vasto (e quindi senza una competenza specifica) e`
perfettamente normale puntare sulla semplicita` a scapito di una
trattazione rigorosa.
Ed e` ampiamente consentito, imho, a quella pagina di contraddirsi per
evitare di parlare un linguaggio incomprensibile ai potenziali fruitori
della pagina stessa.
Se, invece di fermarti alla home page, vai a vedere cosa e` effettivamente
Debian ottieni:
'1.1 What is Debian GNU/Linux? 
Debian GNU/Linux is a particular distribution of the Linux operating system, 
and numerous packages that run on it.'
tratto da :
http://www.debian.org/doc/FAQ/ch-basic_defs.html
-- 
Vincenzo

 
http://www.debian.org/doc/FAQ/ch-basic_defs.html
Per me va bene, dimostra che chi ha scritto l'home page la pensa 
diversamente da chi ha scritto quelle FAQ. Io sono d'accordo con 
l'autore della home page, cmq :)
Ah, e perché mai quello che c'è scritto nelle FAQ sarebbe cosa Debian è 
"veramente", mentre quello che c'è scritto nella home page no? E non 
dovrebbe, la pagina delle FAQ, essere diretta ad un pubblico tanto vasto 
quanto quello che legge la home page?
Azzardo una ipotesi: forse che le FAQ vadano revisionate? O forse va 
revisionata la home page, non so, ma che prendano una decisione! :-P


 l'acqua al proprio mulino?
Cavilli perche' rompi i OO su un testo che ha un valore relativo. Non e'
la definizione universale di OS secondo Debian! Anzi, dubito che chi
scrive questi testi abbia la pretesa di definire che cosa sia un OS e che
cosa non lo sia e di fare discorsi sulla filosofia dell'informatica.
Semmai, ha l'intento di comunicare qualcosa di molto piu' banale.
Poi, chi ha a che fare con distribuzioni tipo debian sa benissimo che
filosofia seguono nella distribuzione dei pacchetti.
-- 
):E...

 filosofia seguono nella distribuzione dei pacchetti.
E cos'ha questo a che vedere con il soggetto del messaggio?
Cmq, come dicevo, argomentazioni tecniche a suffragio della vostra tesi 
non ne ho viste, indi se devo scegliere, scelgo la definizione di OS che 
è più logica, non quella che fa più comodo.


 torto senza portare argomentazioni valide a suffragio delle tue tesi.
Perche' l'unico tuo argomento e' una frase slegata dal contesto. Io t'ho 
fatto notare che il contesto e' diverso da quello che tu pretendi che sia.

 fatto notare che il contesto e' diverso da quello che tu pretendi che sia.
Io non ho notato un bel niente, ma ti do atto di averci provato (forse).



perche' sei in ico. *discussioni* , dunque?
[1]: a chi vuole obiettare sul sistema di pacchettizzazione e su quello di init,
	posso rispondere che in linea teorica:
	- posso evitare qualsiasi sistema di pkt e compilarmi tutto da sorgenti;
	- Slackware e` SystemV-compatible, quindi posso usare lo stesso sistema
	  di init.
	Cio` rende di fatto i due sistemi identici.
Adieu,
-- 
Lestat de Lioncourt		     |			      Ciro Mattia Gonano
 
http://www.CS.UniBO.It/~gonano
   | Undergraduate student of Computer Science
     ICQ#: 52631406		     |		 	at University of Bologna
         <powered by Linux Slackware 8.1-beta2 on Kernel 2.4.18-xfs>

 	Cio` rende di fatto i due sistemi identici.
E così hai dimostrato che se A e B vengono trasformate in C allora non 
sono più nè A nè B. Complimenti.


 esempio, e' un po' meno facoltativo.
una domanda da profano: ma linux mette nel kernel un firewall e comunque
tutto lo stack di rete, vero?
Ora, tanto per fare il cavilloso, il firewall non e' fondamentale per il
funzionamento del sistema, ma nessuno obietta.
Certo, ora che ci penso, immagino che la risposta sia che si puo'
ricompliare il kernel senza iptables.
Ciao
Marco

 ricompliare il kernel senza iptables.
Ma la vera osservazione da fare č questa: se un OS č tale solo se č 
spoglio di tutte le cose inutili al funzionamento del sistema, allora se 
si mette il firewall nel kernel (senza contare il server HTTP e lo stack 
TCP/IP in toto), linux non č piů un OS?
:-P



e cosi` ho dimostrato che sai arrampicarti bene sugli specchi. Complimenti. Vedi
sopra per la spiegazione. Io non *trasformo* . Io *configuro* .



mmm... qualcuno di voi conosce un certo Stefano De Cesari?


 sopra per la spiegazione. Io non *trasformo* . Io *configuro* .
Ed allora rimangono A e B, non diventano C, per tua stessa ammissione. 
Ancora una volta, logica fallace, e questa volta non per le premesse, ma 
per le conclusioni.


 
vedi reply...



anche, ma non e` necessario.


 filesystem?
Bah... l'ignoranza č una brutta bestia... Non hai bisogno di avere un 
filesystem per creare un sistema operativo e funzionante. Non tutti gli 
OS sono uguali e fanno le stesse cose, sai?


 Debian è una distro, l'OS è linux.
qual è la differenza? ad esempio, Lindows è una distribuzione Linux? e 
BlueOS? dove tracci la linea?
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.19. C, C++ and ASM developers
                              and beta testers are welcome!

 Debian dicono..."
No, non lo dicono solo quelli di Debian.
Vedi 
http://www.gnu.org/gnu/linux-and-gnu.it.html
, in particolare:
<quote>
Esiste davvero un Linux; si tratta di un kernel, che queste persone
stanno utilizzando. Ma non si può utilizzare un kernel da solo; un
kernel è utile soltanto in quanto parte di un sistema operativo
completo. Linux è normalmente utilizzato in combinazione con il
sistema operativo GNU: il sistema è fondamentalmente GNU e ha Linux
come kernel.
Molti utenti non si rendono completamente conto della differenza che
c'è tra il kernel, che è Linux, e il sistema completo, che viene anche
chiamato "Linux". L'uso ambiguo del nome non ne facilita però la
comprensione
</quote>
Ciao.
--
BSD is for UNIX-lovers -- linux is for Windows-haters.

 OS".
Equivale a "Debian è un s.o. ***PIU'*** altre cose", come ad esempio:
$Debian=("A"."BC");
ma questo significa che anche se A fa parte di $Debian
(($Debian != "A") && ($Debian != "BC"));

 Equivale a "Debian è un s.o. ***PIU'*** altre cose", come ad esempio:
Certo, ma siccome abbiamo dimostrato che NON c'è contraddizione, allora 
Debian è un SO e linux è il kernel, come da definizione (1) e (3).
Ovvero quello che volevamo dimostrare.


 Ovvero quello che volevamo dimostrare.
Quindi secondo te
((A+B) == A)?????
ROTFL...

 ROTFL...
Caro mio, rotolati di meno, rischi di fare la figura dell'imbecille... 
Non spetta a me insegnarti l'italiano, ci avrebbero dovuto pensare la 
scuola ed i tuoi genitori, ma mi prendo la briga di farti notare che se 
ti dico che un cerchio č qualcosa di piů di una semplice figura, non 
significa che un cerchio non č una figura. Un cerchio č comunque una figura.
Cmq, lo dicono chiaramente che linux č il kernel, non c'č bisogno di 
ricorre alle tue equazioni magiche per contraddirlo. Ed č scritto anche 
nel manifesto GNU. Piů ufficiale di cosě...


 
Per trollare? 
-- 
Renato "Hitman" Salzano / Mexico86 Fan | e-posta:  sonicblast(at)
inwind.it
IHGGer #778 / NapolICErs # 2           | 
http://spazioweb.inwind.it/hitman
GdGnocca #6 / Bassista dei "2ofSpades" | ICQ #75729987 
"Dio dell'ovvietà / qual'è la faccia mia / per questa gente nella via?"


infatti, e io il mio.
E qui chiudo la dissertazione.
Citando uno dei migliori videogames mai apparsi in Terra... "E` stato bello
parlare con te."
(un caffe` da ritirare a Bologna per il primo che mi scova la citazione :P )


 Per trollare? 
Ma vai a cagare, va...



QED (che per chiunque non lo sapesse, significa "Quod erat demonstrandum", i.e.
"Come volevasi dimostrare").
(PS: imposto il Followup-To nell'unico posto dove merita di finire questo
thread...)


 Mette il supporto per l'IP Filtering, 
quindi un'*interfaccia* di programmazione per i firewall. Windows 
include un'*interfaccia* di programmazione per i browser, dove sta la 
differenza?


 differenza?
[Stante il fatto che Explorer non e` solo un'interfaccia...]
Dimmi come posso disabilitare l'"interfaccia per la programmazione per
i browser" senza compromettere l'integrita` del sistema operativo.
Bye,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)           [ 
http://www.radiance.d2g.com/~zefram
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4


Secondo un certo Tanenbaum il sistema operativo ha la funzione di fornire
al programmatore una macchina virtuale piu' semplice da programmare di
quanto lo sia l'hardware sottostante e di gestire le risorse per i processi
, registrandone l'uso e mediando richieste conflittuali di programmi e
utenti diversi.
Sempre secondo questo tizio un sistema operativo andrebbe valutato
considerando il sistema di gestione dei processi (scheduler, ipc), le
funzioni di input/output, la gestione della memoria e il file sistem.
Non so quanto sia attendibile quello che dice costui, io non mi pronuncio.
Ciao


La risposta e' che il concetto di socket, su cui si basano i protocolli
di comunicazione remota, e' un canale di comunicazione tra processi
(remoti in questo caso), cosi' come le pipe, i semafori, la memoria
condivisa, le code di messaggi regolano la comunicazione di processi
locali.Le chiamate di sistema che regolano il flusso di dati per mezzo
di socket, su cui si basa lo stack tcp/ip, su cui si basa iptables, fa
parte (giustamente) del kernel, che e' il sistema operativo linux.
Quando ricompili senza il supporto per iptables, escludi quelle api che
permettono a iptables di funzionare.
Se in qualcuno ricompilasse il kernel di win togliendo prima le api che
permettono ottenere determinate informazioni dallo stack tcp/ip nessun
firewall sotto win potrebbe funzionare.
Ciao


Un PC  funziona appena  è in  grado di eseguire  SW. Ergo,  l'unica cosa
essenziale è il FW (Bios).



Infatti si  può togliere.  È questa la  profonda differenza  rispetto ai
sistemi chiusi e in qui non puoi scegliere cosa ricevere e cosa no.



Un SO si  occupa solo di gestire  le risorse HW e di  offrire servizi ai
programmi applicativi. NON ha contatti con l'utente.
Tutto il resto, è SW applicativo.



Non bevo caffè, però un bianchino lo prendo.



oki, quando vuoi, meglio se lun-mar-mer prima delle 18.20 :)
Fammi sapere!


 come kernel...
In un CD dove c'e' una di quelle che per ora mi limito a chiamare 
distribuzione linux, con kernel, componenti di base, tool e 
applicazioni, dove finisce il sistema operativo e dove iniziano le 
applicazioni?

 nel manifesto GNU. Più ufficiale di così...
Allora, i 6 CD della Mandrake sono tutti per l'installazione del SO + o 
- completo, giusto?

"Gothmog" <fabricius@_REMOVE_ianus.net> ha scritto nel messaggio
news:3CC43ACB.3060400@_REMOVE_ianus.net...

Parrebbe proprio di sì. Dov'è il problema?
Fabio Alemagna

 significa che un cerchio non è una figura. Un cerchio è comunque una figura.
Giusto quindi cio' che ho installato sul mio computer, applicazioni e 
porcate comprese, tra cui vari giochi, sono tutti qualcosa sottoclasse 
di "componente del sistema operativo"?
Disarmante!
Fabio Alemagna, che eredita da Troll Sofisticati, sottoclasse di Troll. 
Speriamo sia un Singletone.

 programmi applicativi. NON ha contatti con l'utente.
Infatti, Explorer, il Finder, il Tracker, la deskbar, il Doc, Sherlock, 
il pannello di controllo, i pannelli di controllo, i sistemi di help e 
cosi' via sono di fatto applicazioni, anche se distribuite nel CD del 
SO; alcune necessarie, altre un po meno, ma la sostanza del discorso non 
cambia.

 Parrebbe proprio di sě. Dov'č il problema?
Allora, per fare un SO un po' piu' ampio, basta che gli allego altri 20 
CD, giusto? Che ne so, gli aggiungo un'enciclopedia in 14 CD e quattro 
giochi, cosi' che anch'essi possano diventare parte del sistema 
operativo, giusto?

"Gothmog" <fabricius@_REMOVE_ianus.net> ha scritto nel messaggio
news:3CC44064.1070606@_REMOVE_ianus.net...

E' ovvio che il tutto deve essere in qualche modo correlato. Una componente
fa parte del SO se fornisce un *servizio* prima al SO, e indirettamente
all'utente che ne fa uso.
Un gioco non fa parte del SO perché non fornisce alcun servizio, mentre un
renderer HTML puň benissimo far parte del SO se viene utilizzato prima di
tutto da altre componenti del SO stesso, come avviene ad esempio con
Windows. In generale una componente fa parte di un SO se e solo se puň usare
altre componenti del SO e puň essere usata da esse tramite un'API ben
definita, e senza il coinvolgimento di un "terzo" elemento quale puň essere
l'umano che controlla il tutto.
In altre parole, una componente fa parte dell'OS se č *integrata* in esso.
Sia ben chiaro che "integrato" non significa "irremovibile".
Si vanno ad aggiungere a quelle componenti anche tutte le utility che
forniscono gli strumenti per l'amministrazione del sistema stesso. Queste
utility non devono per forza di cose essere integrate nel sistema, in quanto
sono uno strumento che prima di tutto viene utilizzato dall'umano che
controlla il tutto.
Nel tuo esempio, un gioco ovviamente non č un servizio, nč un'utility di
amministrazione. Un'enciclopedia, per contro, *potrebbe* essere un servizio:
considerala alla stregua dell'help in linea, solo un po' piů evoluto.
Fabio Alemagna

"Gothmog" <fabricius@_REMOVE_ianus.net> ha scritto nel messaggio
news:3CC43EBB.7010804@_REMOVE_ianus.net...

Questo secondo il tuo autorevole parere, ovviamente, giusto? Potresti dare
una definizione univoca di Sistema Operativo?
Fabio Alemagna

 Speriamo sia un Singletone.
Non riesco a capire cosa, esattamente, nel tuo post dovrebbe in qualche modo
contraddirmi e/o darmi torto. Forse quel "Disarmante!"?
Mi chiedo se, a parte usare una dialettica degna di un bambino di tre anni,
conosci qualche altro modo per cercare di sostenere una conversazione, anzi
no, un "dibattito". Dire "Tu sei scemo, io ho ragione e tu hai torto", come
praticamente fai tu, non denota grandi capacità in tal senso..
Fabio Alemagna

 iniziano le applicazioni?
Questa a quanto pare è una disputa molto accesa (almeno qui) e
difficile da dirimere. Quello che pare certo (e quello che ho quotato
lo conferma) è che il solo kernel non basti a fare un SO. D'altra
parte, in effetti, del solo kernel non te ne fai nulla.
Ciao.
--
BSD is for UNIX-lovers -- linux is for Windows-haters.

 controlla il tutto.
Il punto e` che vi sono SO che non hanno
questi componenti.
Non mi e` chiaro se questi tool siano
obbligatori o facoltativi.
Considera un SO per un sistema embedded,
non vi e` nulla di cio` che descrivi, per
giunta la UI e` parte dell'applicativo,
almeno secondo chi ci sviluppa.
bye,
-- 
  Piergiorgio Sartor

 obbligatori o facoltativi.
Per nulla, perché mai dovrebbero esserlo?


 Benissimo, dov'è il problema? Non sono mica obbligatori.
Allora se non sono obbligatori, un SO
e` tale anche senza, giusto?
Se un SO e` tale anche senza, vuol dire che
quei componenti non determinano il fatto che
un pezzo di SW sia SO o meno.
Quindi non appartengono al SO, ma al resto
del SW, che cade nella categoria applicativi,
di solito (a meno di non definire un'altra
categoria, a questo punto).
Cioe` definisco il SO come il *minimo* set
di SW, che mi consente di cadere nella
definizione di SO.
La domanda sarebbe: perche` il *minimo*?
Magari potrebbe essere il *massimo*...
Il minimo lo posso usare sempre, il massimo no.
bye,
-- 
  Piergiorgio Sartor

 Magari potrebbe essere il *massimo*...
La definizione di SO, per come la vedo io, l'ho già data.


 amministrazione, allora quelle utility *fanno parte* del SO.
Non mi convince.
Se io tolgo quelle utility dal cosiddetto SO,
questo rimane un SO, non e` che diventa altro,
oppure no?
bye,
-- 
  Piergiorgio Sartor

 Edddai, ti appendi a tutti i cavilli!
Le liane sono finite :)
-- 
Davide Inglima - limaCAT

 parte, in effetti, del solo kernel non te ne fai nulla.
D'altra parte, non si puo' continuare a considerare qualcosa come 
facente parte del sistema operativo solo perche' si trova sullo stesso CD.

 all'utente che ne fa uso.
Ok, abbiamo un criterio che a me in questo momento puo' star bene. 
Quindi, tutto cio' che c'e' dentro debian rientra in questa categoria di 
"servizi"?

 parte, in effetti, del solo kernel non te ne fai nulla.
In generale, direi, che di tutto il SO,
da solo, non te ne fai nulla...
Altrimenti avresti un sistema completo,
ti pare?
bye,
-- 
  Piergiorgio Sartor

 solo perche' si trova sullo stesso CD.
Questo certamente no, ma bisognerà considerare almeno un set minimo
di funzionalità che un SO deve offrire.


 da solo, non te ne fai nulla...
Un SO fornisce un set di funzionalità all'utente ed alle
applicazioni che gli permette di essere utilizzato. Un kernel non ne
fornisce abbastanza.


 fornisce abbastanza.
"abbastanza" e` un discorso diverso.
In generale, sia un kernel, che un SO,
sono un pezzo di SW che, da solo, non
ha alcuna utilita`.
Non solo in senso pratico, ma anche in
senso logico.
Cioe` un SO, sempre da solo, non fa o
non consente di fare, nulla di utile
(anche se consente di fare qualcosa).
Ti serve sempre un minimo di supporto
da parte di qualche applicativo.
bye,
-- 
piergiorgio

Gothmog wrote:

Sicuramente non tutto, ma certamente vi rientra il sistema di 
pacchettizzazione, la gui, la struttura delle directory, gli script e 
gli strumenti di amministrazione, e varie ed eventuali.


 
Difficile che possa esserci... risiedo a Napoli ^____^


Il  Mon, 22  Apr 2002  18:47:55 +0200,  Gothmog battendo  sulla tastiera
scrisse:

Esatto. Sono applicazioni, non parte dell'SO.  Che poi siano date o meno
in bundle con il SO è un'altro problema...


 da parte di qualche applicativo.
Diciamola così:
fa parte del SO tutto ciò che è strettamente necessario per offrire un
set minimo di funzionalità, tali che chi programma un applicativo per
detto SO, lo possa fare senza doversi interfacciare con l'hw
sottostante. Da questo si evince che il kernel da solo non è un SO.


 sottostante. Da questo si evince che il kernel da solo non č un SO.
Uhm, a questo punto, mi sa, che bisognba
definire anche "kernel".
Se il kernel e` l'insieme dei driver (e basta)
allora ti fornisce esattamente cio` che ti
serve per interfacciarti con l'HW (questo per
definizione di driver).
Oppure kernel e` altro...
bye,
-- 
  Piergiorgio Sartor

 Oppure kernel e` altro...
Beh, direi che dipende da come è progettato il kernel (e quindi
dipende dal SO), ma in Windows questo non è certo sufficiente, ed in
linux non penso neppure.


 linux non penso neppure.
Il kernel, il Linux, credo faccia partire "init",
che potrebbe essere un altro applicativo.
Direi che non serve altro, tutti i "tool" di
configurazione necessari possono essere integrati
nell'applicativo, non e` che debbano essere per
forza separati.
Tra l'altro questo e` proprio quello che fanno
le distribuzioni Linux embedded (BlueCat, Lineo),
cioe` ti consentono di fare un singolo applicativo,
che contiene tutto cio` che e` necessario per
funzionare sopra il kernel.
bye,
-- 
piergiorgio


Appunto: sono queste a fornire funzionalità all'utente.
Il  SO  _NON_  ha  contatti  con  l'utente,  ma  solo  con  i  programmi
applicativi.
Esatto,  windows  non è  (solo)  un  SO, ma  un  bundle  di SW  tra  cui
incidentalmente c'è anche un SO.


 tra  cui incidentalmente c'è anche un SO.
E chi se ne frega? Windows è un prodotto, dentro ci mettono quello che 
gli pare. E se dicono che Windows ha bisogno di un browser, Windows ne 
ha bisogno. Perchè non è un sistema operativo, e non sono interessati a 
vendere solo il sistema operativo ad utenti finali (all'ingrosso lo 
vendono, a pezzi o tutto, codice sorgente incluso). Come delle 
automobili (che palle) difficilmente ti vendono solo il motore, 
difficilmente vendono motori un'unità alla volta, difficilmente il 
motore acquistato separatamente ha lo stesso prezzo che avrebbe 
acquistato assieme a tutta l'auto, difficilmente cedono il progetto a 
chiunque, eccetera eccetera eccetera
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.19. C, C++ and ASM developers
                              and beta testers are welcome!

 "senza sistema operativo"
Beh, un orologio digitale e` un computer
e dubito abbia un SO.
Ma potrei portarti anche il computer della
bicilcetta come esempio, spesso un uC a 4 bit,
sicuramente senza SO.
E che dire del computer dell'automobile?
Beh, forse quelli piu` avanzati hanno un SO...
bye,
-- 
piergiorgio

 Beh, un orologio digitale e` un computer
[cut]
Parliamo di computer che siano in grado di svolgere qualcosa
di più di un unico compito...


 forza separati.
Che ci sia un altro applicativo che offra tutte le
funzionalità necessarie, o che ce ne siano molti, non cambia
la question. Da solo il kernel (linux) *non* basta.


 Beh, un orologio digitale e` un computer e dubito abbia un SO.
ha un clock, ha sicuramente degli interrupt per gestire la pressione 
dei pulsanti, ha persino un display a bitmap. E' un sistema operativo 
realtime a singolo processo


 la question. Da solo il kernel (linux) *non* basta.
A cosa non basta?
Io ho il kernel + applicativo e` tutto fuziona
come da specifiche.
Il kernel basta ed avanza per far funzionare un
applicativo.
Che poi sia meglio spezzettare le funzionalita`
su piu` SW (che non chiamo "applicativi" per 
evitare confusione), questo e` un discorso diverso.
Il kernel, di suo, e` sufficiente per avere un sistema
che fa qualcosa di utile.
bye,
-- 
  Piergiorgio Sartor

 di più di un unico compito...
Beh, un orologio digitale ha anche il timer,
magari in countdown, allarme, direi che sono
gia` tre compiti ben distinti.
Tempo fa vi erano quelli con la calcolatrice...
bye,
-- 
  Piergiorgio Sartor

 realtime a singolo processo
No, e` un applicativo real-time, non vi e`
il layer SO per la gestione dell'HW.
Vi e` un unico SW che, ad ogni interrupt,
legge la "tastiera", compie un'eventuale azione,
aggiorna il display.
Non esiste SO. Non esiste un pezzo di SW separato.
Questo perche` il SO non e` un applicativo,
altrimenti dovremmo ridefinire tutto daccapo.
bye,
-- 
  Piergiorgio Sartor

 gestione dell'HW.
credo che la prima pagina del libro di Tanenbaum sui sistemi operativi 
spieghi che questo è irrilevante


 come da specifiche.
Appunto. Kernel *+* applicativo, non kernel e_basta.


 Tempo fa vi erano quelli con la calcolatrice...
Due...


 spieghi che questo è irrilevante
Per cosa, per la definizione di applicativo
o per quella di SO?
Dato che, nel caso dell'orologio, sicuramente
vi e` un applicativo che si interfaccia con
l'utente, dimmi dove sta il SO.
bye,
-- 
piergiorgio

 Appunto. Kernel *+* applicativo, non kernel e_basta.
Neanche SO e basta, se e` per questo.
Quello che voglio dire e` che per far
funzionare un applicativo, basta il
kernel, non serve tutto il SO.
bye,
-- 
piergiorgio

 Sempre di un unico compito si tratta.
Per me sono compiti molto diversi.
Gia` programmare l'allarme e` un task
non da poco.
bye,
-- 
piergiorgio

 kernel, non serve tutto il SO.
No. Un applicativo per girare sopra il solo kernel (parlando
di Windows e di linux) può essere costretto ad interfacciarsi
con l'hw sottostante (chiaramente dipende da cosa fa). Il solo
kernel non è sufficiente.



Dipende da cosa  è etichettato come "kernel". Il comune  kernel linux ad
esempio è un SO in tutto, dalla definizione di sopra.
Il cosidetto "kernel" windows, no. 


 non da poco.
Sono sempre strettamente collegati.
E comunque dire che un SO non è necessario in un computer è
un'assurdità, perché anche se non sarà presente un SO in senso
stretto, le funzionalità che offre il SO, saranno comunque
incluse nell'applicativo che girerà sul computer.
Ed è questo quello che intendeva Juliet con la sua citazione
del Tanenbaum.


 kernel non è sufficiente.
A questo serve il kernel, ad interfacciarsi
all'HW sottostante... Dato che contiene i driver.
Quindi non capisco dove sia il problema.
O cosa tu intenda con "interfaccirsi all'HW
sottostante".
Io capisco che, se devo accedere,
dall'applicativo, per es. alla seriale,
uso /dev/seriale, il che e` un
interfacciamento diretto con il kernel.
Tu cosa intendi?
bye,
-- 
piergiorgio

 incluse nell'applicativo che girerà sul computer.
Questionabile, sia in senso tecnico
che in senso logico.
Come dire che e` un SO tutto quello
che e` un SO.
Io non credo che avere le funzionalita`
di un SO, ammesso che sia sempre vero,
costituisca comunque l'avere un SO.
Resta poi sempre il dubbio sulla definizione
di "funzionalita` del SO" e su a chi si
rivolgono queste funzionalita` (sono solo
interne? Sono esportate all'esterno?)
Vi deve essere un'architettura sottostante
che consenta di identificare il SO come
tale, altrimenti qualunque cosa e` qualunque
cosa, basta "massaggiare" i contesti.
Potrei dire che tutto, alla fine, e` applicativo
ed il SO non esiste.
bye,
-- 
piergiorgio

 costituisca comunque l'avere un SO.
No. Dire che un computer può girare senza SO non è per nulla
significativo, perché comunque certe funzionalità dovranno
essere offerte da qualche sw. Che poi si tratti di un SO (come
si intende comunemente) o dall'unico applicativo che gira sul
hw, è ininfluente.
Ciao.
--
BSD is for UNIX-lovers -- linux is for Windows-haters.

 Tu cosa intendi?
Che il kernel (di Windows sicuramente, ma direi anche di
linux) non offre tutto ciň che serve.


 linux) non offre tutto ciň che serve.
Uhm, direi che quello di Linux offre
tutto cio` che serve, e` possibile
accedere all'HW attraverso il kernel,
per ogni periferica, al limite tramite
/dev/mem o similare.
Ma puo` essere che abbiamo una diversa
idea di "cio` che serve", non e` che
hai qualche esempio?
bye,
-- 
piergiorgio

 hw, è ininfluente.
Cambia completamente il punto di vista,
non hai piu` distinzione fra parti.
Difatti, poi, se l'applicativo si occupa
di gestire l'HW (per farla semplice), le
"funzionalita`" del SO non vengono "offerte"
affatto, a nessuno.
Esempio: una funzionalita` del SO e` quella
di poter accedere alla seriale.
Cioe` esiste un ben definito entry point, che
consente ad altro SW di accedere al dispositivo.
Se non uso il SO, potrei scrivermi un set di
funzioni con lo stesso scopo, ed avere un
simile entry point.
Ma potrei, come succede nei casi minimi,
accedere alla seriale nel mezzo del loop
principale del programma, non esiste piu`
nessun entry point, ne` alcuna funzionalita`
offerta a nessuno. Il codice di accesso
all'HW si "confonde" con tutto il resto.
Quindi non esiste piu` la "funzionalita`"
che normalmente e` offerta da quello
strato di SW che chiamiamo SO.
bye,
-- 
piergiorgio

 l'utente, dimmi dove sta il SO.
applicativo? quello è il sistema operativo
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.19. C, C++ and ASM developers
                              and beta testers are welcome!

 applicativo? quello è il sistema operativo
No, e` l'applicativo, dato che e`
"l'applicazione" che l'utente usa...
bye,
-- 
piergiorgio

 "l'applicazione" che l'utente usa...
dal mio punto di vista è il sistema operativo, perchè fa funzionare 
l'hardware, pardon, la macchina. Come la mettiamo?


 l'hardware, pardon, la macchina. Come la mettiamo?
La mettiamo che il SO non basta da solo
(per definizione), serve l'applicativo.
Dato che il SW dentro l'orologio non e`
distinguibile in due parti, deve per
forza essere un applicativo.
bye,
-- 
piergiorgio

 affatto, a nessuno.
A sč stesso.


 hai qualche esempio?
libc? tanto per dire la prima che mi viene in mente.


 forza essere un applicativo.
E se fosse entrambi? Nunsepo'? :-|
Saluti.

 libc? tanto per dire la prima che mi viene in mente.
Uhm, e` linkata staticamente...
Inoltre tutto quello che fa libc, puo`
farlo l'applicativo, non solo con link
statico, ma con vera e propria inclusione
di codice C (o quello che e`).
bye,
-- 
piergiorgio

 A sč stesso.
Nooo, perche` non esistono queste
funzionalita`, come lo devo spiegare?
bye,
-- 
piergiorgio

 E se fosse entrambi? Nunsepo'? :-|
Uhm, il fatto e` che noi facciamo
due categorie: il SO e l'applicativo.
Da un punto di vista architetturale
si deve trovare una linea di separazione
tra i due oggetti.
Vi sono casi, e qui entra il tuo ragionamento,
in cui questa distrinzione non si puo`
fare o e` difficile da farsi.
Da un punto di vista "tradizionale",
gli applicativi sono sempre esistiti,
i SO no!
I SO sono stati introdotti nel momento
in cui si e` sentita la necessita` di
avere questa "separazione", per tutta
una serie di motivi di convenienza.
Nel caso di micro-applicativi, il SO e`
integrato nell'applicativo. A volte a
tal punto da non poter piu` essere trovato.
In queste situazioni, il SO non esiste!
Certo si puo` provare a scivolare sugli
specchi con ragionamenti riguardo le
funzionalita` implicite del SW in questione,
ma la discussione diventa un pelo surreale.
Certo, ci sono casi e casi, tutto il
discorso serve solo a sottolineare questo.
Quando si parla di SO, non si parla solo
di windows o di Unix, vi sono tutta una
serie di SW che sono chiamati tali, con
funzionalita` diverse ed architetture
altrettanto diverse.
Generalizzare diventa difficile.
bye,
-- 
piergiorgio

 di codice C (o quello che e`).
Non ho capito. Cosa significa "inclusione di codice C"?


 funzionalita`, come lo devo spiegare?
E come ci accedi all'hw? Con la magia o ci sarà del codice che
lo effettua?


 In queste situazioni, il SO non esiste!
Ti stai troppo "impuntando" troppo su una definizione,
perdendo di vista il vero punto focale.
Nel caso di micro-applicativi il SO non sparisce, ma si
*confonde* con l'applicativo stesso.


 Non ho capito. Cosa significa "inclusione di codice C"?
Se il mio programma usa "malloc()" che e`
nella libc e che mappa la malloc del SO,
posso prendere il codice C che costituisce
la "malloc()" (dalla libc) e` schiaffarlo
dentro il mio programma.
Cosi` non mi serve piu` la libc, il mio
applicativo chiamera` direttamente la
funzione del SO, cosi` come faceva libc.
bye,
-- 
piergiorgio

 lo effettua?
Leggo un registro in HW, ti pare che
questa sia una funzionalita` paragonabile
ad aver un device virtuale?
La semplice lettura o scrittura di un
indirizzo di memoria in modo assolutamente
indistinguibile da altre operazioni del
programma non credo si possa ragionevolemente
considerare una "funzionalita`", se non
altro per come si concepisce una "funzione".
Non esiste un oggetto SW, ben definito,
che fornisca questa "funzionalita`",
il programma che gira fa tutto in un blocco
solo, senza soluzione di continuita`.
Mai programmato PIC o robe tipo 68HC11?
bye,
-- 
piergiorgio

 *confonde* con l'applicativo stesso.
Esattamente quello che dico io, pero`
al programmatore viene chiesto di
fare un applicativo, non un applicativo
con SO integrato.
Il fatto che il SO sia "fuso" nell'applicativo
e` una mera considerazione accademica, per
chi, come il buon Andrew, *deve* per mestiere
sottolineare l'aspetto SO del SW.
In pratica, nel caso di micro-applicativi,
non si parla mai di SO, ma solo di applicativo,
poiche` il concetto di SO *nasce* come entita`
ben separata, cioe` nasce nel momento in cui
si decide, per ragioni di convenienza, di
astrarre e separare un pezzo di codice per
dargli *vita propria*.
Quindi possono esistere sistemi (che operano),
senza un SO, dove per SO si intende un pezzo
di SW ben definito e delineato che svolge
alcune attivita` di supporto per l'applicativo
(ti sta bene questa definizione?).
E ripeto, che poi qualcuno ci voglia trovare
un SO lo stesso, faccia pure, ma direi che
sta solo facendo un esercizio dialettico.
bye,
-- 
  Piergiorgio Sartor

 sta solo facendo un esercizio dialettico.
Sinceramente a me pare l'esatto contrario, cioè che il voler
affermare che un computer possa funzionare senza un SO stia
solo facendo un esercizio dialettico, in quanto l'applicativo
che ci girerà sopra farà le veci di un SO.


 funzione del SO, cosi` come faceva libc.
Ma visto che il SO nasce proprio per evitare la duplicazione
inutile e dannosa di codice, un simile comportamento è
impensabile (non parliamo poi di come ne godrebbe la
portabilità del codice), per cui la libc *deve* fare parte del
SO.


 Mai programmato PIC o robe tipo 68HC11?
Fortunatamente no...
Ciao


 SO.
Sono d'accordo, come ho gia` detto.
In generale la procedura e` quella di
avere piu` layer, SO, libc, etc.
Per i motivi che tu esponi.
Pero` vi sono casi, come le applicazioni
embedded, in cui questi layer vengono
ridotti, per motivi di praticita`.
Per esempio avendo un unico eseguibile
che contiene le funzionalita` che interessano,
cioe` integrando parte della libc e di
altri tool per la gestione del SO in
un unico programma.
Non e` pratica comune, ma si usa.
Quello che mi preme sottolineare e` il
fatto che il mondo non e` tutto fatto
da PC desktop con SO tipo win ed applicativi
tipo Word, ma esistono anche altre realta`,
non meno importanti, se non altro per
il giro di affari.
bye,
-- 
piergiorgio

 Funzioni, queste sconosciute...
Infatti, ma quando devi scrivere
un programma che stia in 256 byte
di EEPROM, avendo a disposizione
512 byte di RAM... ti devi adattare... :-)
bye,
-- 
piergiorgio

 che ci girerà sopra farà le veci di un SO.
Questa mi pare faccia un po' di confusione...
bye,
-- 
piergiorgio

 il giro di affari.
Lo so bene, ed è proprio per questo che non si riesce a dare
una definizione univoca, precisa e dettagliata di SO.


 512 byte di RAM... ti devi adattare... :-)
Beh, non è una cosa che ho mai fatto, ma mi pare che
utilizzare funzioni che offrano una certa funzionalità e non
ripetere il codice più volte, sia la prima cosa da fare per
risparmiare spazio...
Ciao.


 Questa mi pare faccia un po' di confusione...
Perché?
Ciao


 Perché?
Perche` assume cose fuori dalle
convenzioni.
In particolare assume che il SO sia
un entita` sempre presente, il che
non e` vero, dato che i SO nascono
dopo gli applicativi.
Cioe` tu dai all'applicativo proprieta`
che un tempo neanche erano definite,
mentre gli applicativi esistevano.
bye,
-- 
piergiorgio

 risparmiare spazio...
Certo, dando per scontato che la chiamata
a funzione occupi meno spazio della
funzione stessa... :-)
bye,
-- 
  Piergiorgio Sartor

 dopo gli applicativi.
No, assume che qualcosa che interagisca con l'hw per fornire
un'interfaccia all'utente o ad altri applicativi è sempre
presente. Che questo sia un SO vero e proprio od un unico
applicativo è ininfluente.
Ciao.


 applicativo è ininfluente.
Ininfluente per cosa?
Qui si parla del fatto che un qualcosa che
noi chiamiamo SO sia presente o meno in
certe macchine o sistemi o computer.
Ti ripeto che il concetto di SO nasce dopo
il concetto di applicativo o di SW applicativo,
se preferisci.
Quindi e` esistito un tempo in cui c'erano
macchine che funzionavano senza SO. Per il
semplice fatto che non ci si immaginava
neanche il concetto.
Ed esiste ancora, dato che esistono
micro-sistemi che hanno SW, sono computer
e non hanno SO.
Che poi vi sia tutta una serie di ragioni
per cui in certi (molti?) sistemi sia
conveniente, se non necessario, avere un
SW che svolga delle funzionalita` specifiche
che noi identifichiamo come SO, sono
d'accordo con te.
bye,
-- 
  Piergiorgio Sartor

 e non hanno SO.
Credo di avertelo già detto un bel po' di volte. Il SO in
questo caso si confonde con l'applicativo.


 questo caso si confonde con l'applicativo.
Quindi non esiste.
O meglio esiste solo nel mondo dei sogni,
cioe` dove si vuole per forza farlo esistere.
bye,
-- 
piergiorgio

 cioe` dove si vuole per forza farlo esistere.
No, che tu abbia idee diverse dalle mie è una cosa, ma "si
confonde" non vuole dire "non esiste"; è un concetto diverso.


 l'invenzione di qualcosa.
Invenzioni, appunto.
L'ossigeno non mi pare sia una
invenzione...
A parte questo, secondo il tuo
ragionamento il SO e` sempre
esistito, solo che ad un certo
punto qualcuno lo ha chiamato SO.
A me pare che ad un certo punto
qualcuno abbia *raccolto* certe
funzionalita` e le abbia chiamate
SO. Il SO non sono le funzionalita`,
ma la *raccolta* di queste funzionalita`.
E quando questa *raccolta* non esiste,
non esiste neanche il SO.
bye,
-- 
piergiorgio

 non esiste neanche il SO.
Fiori sparsi non li chiami "mazzo di fiori", ma sempre fiori
sono (o no?). E ci sarebbe da discutere su quanti fiori sono
necessari per formare un mazzo...


 cioe` dove si vuole per forza farlo esistere.
Rispondi a questa semplice domanda: quella "cosa" che gira lì sopra, fa
tutto quello che farebbe un sistema Operativo? Se la risposta è
affermativa, allora *è* un sistema operativo.
Fabio Alemagna

 necessari per formare un mazzo...
Esattamente!
Il SO e` il mazzo di fiori.
Altrimenti e` come dire che l'acqua,
che e` fatto di ossigeno ed idrogeno,
ha le stesse "funzionalita`" dell'ossigeno
e dell'idrogeno.
Ma se vai sotto acqua, dubito tu riesca
a sopravvivere, dato che dell'ossigeno
che c'e`, non puoi usare le "funzionalita`".
Stesso discorso per un vocabolario, il fatto
che contenga tutte le parole (ed esempi),
non vuol dire che abbia le stesse "funzionalita`"
di un libro di Biagi.
Cosi` come il libro di Biagi non ha le stesse
"funzionalita`" di un libro di Benni.
L'ordine delle cose serve per creare le
categorie, in quei settori dovi l'ordine
puo` creare la differenza.
Inoltre se "si confonde", vuol dire che non
su puo` distinguere (in alcun modo) e se
non si puo` distinguere, come fai a sapere
che esiste?
bye,
-- 
  Piergiorgio Sartor

 affermativa, allora *è* un sistema operativo.
No, mi spiace, il fatto che la cariola
trasporti sassi, non la fa diventare
un camion, e viceversa.
bye,
-- 
  Piergiorgio Sartor

 un camion, e viceversa.
?? Scusa ma... che razza di paragone è? Il camion trasporta SOLO sassi? 
Se sì allora è una carriola un po' più grande, altrimenti è ANCHE una 
"carriola", nel senso che ne ha tutte le funzionalità.
Se quella cosa fa tutto ciò che fa un SO, allora *è* un SO, se inoltre 
fa tutto ciò che fa un applicativo, allora *è* un applicativo.
I due concetti posso benissimo coesistere, non c'è alcuna ragione per 
separarli quando non si DEVE.
Se prima non esisteva il concetto di Sistema Operativo, come hai ben 
detto tu, allo stesso modo non esisteva neanche quello di Applicativo: 
entrambi i concetti sono nati allo STESSO TEMPO.
Prima esisteva il computer, che macinava calcoli. Non esisteva 
applicazione, non esisteva Sistema Operativo.
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
                                       Bertrand Russell
                                       The Philosophy of Logical Atomism

 entrambi i concetti sono nati allo STESSO TEMPO.
Affatto, si parla di SW applicativi prima
del concetto di SO.
Dopo, si e` concentrato in applicativo un
concetto piu` specifico.
bye,
-- 
  Piergiorgio Sartor

 concetto piu` specifico.
Pier, si parlava di *programmi*, non di applicativi.


 Pier, si parlava di *programmi*, non di applicativi.
Ti sto cercando di dire che i termini
erano confusi, la distinzione che facciamo
(tu, io e gli altri) adesso e` diversa da
quella che c'era in passato.
E comunque non ha importanza.
Diciamo "programmi".
Esistono computer su cui ci gira un programma,
senza avere il SO.
bye,
-- 
  Piergiorgio Sartor

 che esiste?
Se "si confonde", vuole dire che non si può distinguere, come
fai a sapere che l'applicativo esiste? :-P
Il fatto è che io non sto dicendo che il SO esista sempre ed
in ogni caso, ma che ha poco senso dire che un computer possa
girare senza SO, perché le macchine che non hanno un SO
"secondo l'accezione comune del termine", hanno comunque del
sw che svolge le stesse funzioni di un SO.


 caRRiola ;)
Cmq, solo a scopo informativo e senza alcuna vena polemica:
anche cariola è corretto (termine popolare, ma corretto). ;-)


 anche cariola è corretto (termine popolare, ma corretto). ;-)
Popolare di dove? :)


 Popolare di dove? :)
Direi popolare in genere, perché anche qui da me (Liguria) si
sente dire cariola.


 sw che svolge le stesse funzioni di un SO.
Capisco il ragionamento "black box",
qualunque cosa che si muove (in salita,
magari), deve avere un motore.
Non ho bisogno di "vederlo", perche` deve
esserci per fornire quella funzionalita`.
Quello che io dico e` che questo ragionamento
non e` *generalmente* valido per il software,
ma e` *comunemente* valido, su questo sono
d'accordo.
E qui (se mi permetti chiudo una cosa ed
apro un'altra), si entra nel discorso della
definizione di SO.
Quello che leggo a volte e` una definizione
*comunemente* valida, ma non *generalmente*
valida.
Per esempio sulla questione UI o non UI.
Forse, per chiarire le cose, bisognerebbe
circoscrivere l'area di interesse e
magari riferirsi *solo* ad alcuni casi,
come per esempio i PC desktop.
bye,
-- 
piergiorgio

 come per esempio i PC desktop.
Infatti, cosě andrebbe meglio, ma rimarrebbero ancora punti
non chiari.


 non chiari.
Gia`, ma se non si inizia a tagliare un po'
l'area di interesse, non se ne cavera` mai
un ragno dal buco...
bye,
-- 
  Piergiorgio Sartor

 un ragno dal buco...
Certo, ti ci avvicini, ma la soluzione non la troverai mai. A
meno di non dare una definizione che sia generica.


 
Idee confuse. Bisognerebbe dire cosa "sono le funzioni di SO".
E  accedere  a  un  HW  non  significa fare  "le  funzioni  di  un  SO",
incidentalmente.
E in tal senso, una PSX gira senza SO.
-- 
Renato "Hitman" Salzano / Mexico86 Fan | e-posta:  sonicblast(at)
inwind.it
IHGGer #778 / NapolICErs # 2           | 
http://spazioweb.inwind.it/hitman
GdGnocca #6 / Bassista dei "2ofSpades" | ICQ #75729987 
"Dio dell'ovvietà / qual'è la faccia mia / per questa gente nella via?"