Newsgroup: it.comp.os.dibattiti
Titolo: AtheOS: lo conoscevate?

Home page:
http://www.atheos.cx/
Un progetto molto promettente. Per voi fissati: sì, supporto POSIX. Sì, 
ha un X-Server. Ma non l'X-Server a cui vi hanno abituati: questo non 
usa TCP (avverto un urlo soffocato) ma il sistema di messaging (mi 
ricorda qualcosa! MI RICORDA QUALCOSA!). Non solo, questo X-Server è nel 
kernel (odo un tonfo). Continua a ricordarmi qualcosa. Ah, leggo che 
tutti i programmi sono potenzialmente multithreading, dato che la 
creazione di un processo comporta la creazione di un primo thread - 
anche questo mi sembra di averlo già visto. File system copiato dal 
BeFS, quindi ottimo (grande capo dire BeFS ottimo. Grande capo sempre 
ragione. Augh!)
Software supportato (parecchio. Soprattutto, tutto l'occorrente per un 
sistema self-hosted e completamente compatibile con Unix. Compatibilità 
anche a livello binario - eseguibili ELF):
http://www.atheos.cx/software.php3
Ah, sempre a proposito di software supportato, tengo a far notare, nel 
caso vi sfuggisse da una lettura superficiale della pagina, che:
D:\home\Hyperion>nc 
www.atheos.cx
 80
GET / HTTP/1.0
HTTP/1.1 200 OK
Date: Sun, 29 Jul 2001 01:11:14 GMT
Server: Apache/1.3.9 (AtheOS)
X-Powered-By: PHP/3.0.14
Connection: close
Content-Type: text/html
Difetti? funziona solo su Intel 586 e superiori (il kernel contiene poco 
o niente ASM, quindi potrebbe essere semplice da portare). Usa 
unicamente le funzioni del BIOS per l'accesso ai dischi (niente CD-ROM, 
ad esempio). I thread hanno tutti la stessa priorità di schedulazione 
("int main(void){while(1);}" in AtheOS è un DoS in piena regola)


"AtheOS is a free desktop operating system (currently) under the GPL
lisence."
^^^^
wow! abbiamo il linus torvald del 2000!
adesso copio anch'io un po' di codice da linux, il filesistem di beos, il
tutto condito da un pizzico di api et... voila'...
Gran cosa questa gpl, adesso capisco perche' chi mangia con l'informatica ci
si dedica mezz'ora prima di andare a letto.

("int main(void){while(1);}" in AtheOS è un DoS in piena regola)
Rettifico, di windows 3.0.
Quindi, chi se ne frega?
-- 
ciao, | "You're one of those condescending Unix computer users!"
Marco | "Here's a nickel, kid. Get yourself a better computer"  -- Dilbert
      | (Ri)scoprire fidonet: 
http://bbs.bofh.it

Quindi, chi se ne frega?
Devo ancora avere un dischetto con Linux 1.0 da qualche parte. Vogliamo 
farci queste quattro risate?

farci queste quattro risate?
Lo puoi scaricare da 
www.kernel.org
 :-))
Provalo insieme alla voce di Torvalds che dice come si pronuncia...
CIAO!
Andrea

farci queste quattro risate?
Come vuoi, ma linux non ha mai usato il BIOS per accedere ai dischi e ha
sempre avuto uno scheduler funzionante.


 sempre avuto uno scheduler funzionante.
Be', il BIOS e' un ripiego momentaneo, fino a quando ci saranno dei
drivers specifici per l'HW. E' una sola persona a lavorarci...
Fabio Alemagna

Rispondo alla domanda: si' (ci ho fatto un giretto sul sito di regente, metti
ad inizio mese), e _SECONDO_ME_ si dovrebbe pensare ad un sistema del genere
per creare un environment completamente ad oggetti, (altro che mettere
l'ennesimo strato su linux+x11+...).
La gui di Atheos mi pare sia gestita dall'OS stesso.
-- 
Davide Inglima, limaCAT

 Quindi, chi se ne frega?
Chi ha voglia di svilupparlo. Allora quando il buon Linus posto'
il primo messaggio sul suo pupo, gli dovevi rispondere allo stesso modo.
Addio

 
http://www.atheos.cx/
Lo conosco[1]. L'ho scaricato due volte, ma non sono mai riuscito ad
installarlo (la prima volta per mancanza di voglia, la seconda per un
errore che mi dava sul pacchetto tar.gz usando i tool che si trovano sul
secondo dischetto)
Henryx
[1] la mia indole mi porta ad esaminare qualsiasi cosa che sia
alternativa a cio` che ci e` stato imposto come standard
-- 
Se volete contattarmi, non fatelo. E' la scelta migliore per 
salvaguardare la vostra salute mentale.

 wow! abbiamo il linus torvald del 2000!
DLIN DLON
Coloro che hanno da dire solo commenti velenosi e poco inerenti con il
manifesto del ng sono pregati di andare a rompere i maroni da un'altra
parte
DLIN DLON
Henryx


 Quindi, chi se ne frega?
Frega a tutti quelli che vorrebbero qualcosa che non sia linux (ma che
non sia nemmeno win$ ) e che abbia qualche speranza di sopravvivere


 Quindi, chi se ne frega?
Si, ma vuoi mettere?
Il mio codice GPLd ce l'ha piu' lungo del tuo.
-- 
Davide Inglima, limaCAT

 sempre avuto uno scheduler funzionante.
Si saranno sfogati sulla VM.
-- 
disclaimer: not speaking for anybody but me.

l'informatica ci si dedica mezz'ora prima di andare a letto.
In compenso il tizio è riuscito ad ottenere da solo quello che 9 anni e 
tre quarti (a proposito, pronti al compleanno del pinguino?) di 
appassionati, professionisti, semi-professionisti e un sopravvalutato, 
strombazzatissimo secchione finlandese non sono arrivati nemmeno a 
concepire. Per me è meglio così, secondo il mio punto di vista quel 
codice sorgente non è stato rubato, è stato valorizzato. Pensa se il 
nostro orizzonte visibile si limitasse a Linux. Bella libertà di scelta

e ha sempre avuto uno scheduler funzionante.
questione di priorità. In compenso quanto c'è voluto perchè Linux avesse 
una GUI funzionante? (non dico "veloce" perchè ho smesso di sperarci...)

 una GUI funzionante? (non dico "veloce" perchè ho smesso di sperarci...)
Si intuisce che per te un OS senza una GUI non e' accettabile ma non e'
mica cosi' per tutti sai.
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

 una GUI funzionante? (non dico "veloce" perchè ho smesso di sperarci...)
Ma la GUI non fa parte dell'OS, e` solo un applicativo,
cosi` come lo e` la shell.
bye,
-- 
  Piergiorgio Sartor

 concepire.
Evvai con le gare a chi ce l'ha più lungo. Certo che cosi' si capiscono
veramente pregi e difetti di un SO!
--
Medaglia, medaglia, medaglia....
Mutley
(alias Marco Costamagna)

 mica cosi' per tutti sai.
"Insomma e' solo questione di manico, cioe' il pezzo di carne fra la
tastiera e il monitor, non per vantarmi ma VI lo usano solo gli utonti (la
V sta per VISUAL come in VISUAL BASIC), e quindi io configuro tutta la mia
server farm una macchina per volta, con "ed", il vero editor per uomini
veri e irsuti."


cosi` come lo e` la shell.
Unix non è il mondo...

 cosi` come lo e` la shell.
ma questo non vuol dire che siano meno necessari o meno importanti...
configuralo tu senza nessuna shell...
Detta in altre parole, linux sara` solo il kernel, ma un sistema operativo
"general purpose" ha bisogno di qualcosa di piu`... almeno di una shell
e i minimi comandi per interagire con esso...
--
ciao, Mirco.
[ Icq#:51640305 ] [ 
http://spazioweb.inwind.it/mmos2/
 ]

concepire.
*plonk*
-- 
Davide Inglima, limaCAT

 *plonk*
Se mi plonki KJK, si è detto tutto sul grado di tolleranza di questo ng.
Saluti.
--
Wilmer Ricciotti
wi...@bigfoot.com

nostro orizzonte visibile si limitasse a Linux. Bella libertà di scelta
Non credo che su questo si possa discutere.
-- 
Saluti,
    Mardy
http://www.interlingua.com

*plonk*
Vedo che la liberta' di pensiero viene sempre apprezzata dagli amici
del pinguino..
Ciao
Francesco

 veri e irsuti."
Seeeh, BUM ! E Raffaella Carra' ieri ha domato un drago, poi Merlino e'
venuto a mangiare nella sua mano.


Se mi plonki KJK, si è detto tutto sul grado di tolleranza di questo ng.
Ne hai letto anche il post?
A proposito, ti sei perso una "e" per strada nella risposta ^_^.
Felice Claudio
-- 
di buone intenzioni e' lastricata la strada per l'inferno,
che lastricano le cattive intenzioni?

 Unix non è il mondo...
Eh? Che vuoi dire?
Neache i computer sono il mondo, se e` per questo,
sfortunatamente, pero`, qui si discute (in buona parte)
di OS, per cui...
bye,
-- 
  Piergiorgio Sartor

 e i minimi comandi per interagire con esso...
No! Non ha bisogno di nessuna shell, non DEVE averne bisogno.
Diciamo che, in generale, e` buona abitudine e pratica
fornire un minimo di interfaccia utente.
Questa e` comunque una visione limitata dell'OS,
certo, forse maggioritaria, ma limitata.
Qui ricadiamo ancora nelle definizioni, cosa gia`
discussa in precedenza.
Vi e` un kernel, vi e` un OS, vi sono gli applicativi.
Tutto e` SW, ma per comodita` viene categorizzato
secondo questi criteri.
Ora, se sostituisco la shell con un applicativo adatto,
il tutto puo` funzionare come e meglio di prima, il che
vuol dire che la shell e` un applicativo e non parte
del sistema operativo.
A maggior ragione la GUI. Quindi l'affermazione "Linux non
ha una GUI decente" e` assolutamente priva di senso se
ci si riferisce a Linux come sistema operativo (che e`,
spesso, l'argomento di questo NG).
D'altro canto si potrebbe sempre affermare che, pur non
avendo una GUI decente, conserva sempre la possibilita`
di averla in futuro, il che non e` poco.
bye,
-- 
  Piergiorgio Sartor


La tua affermazione "la gui e' solo un applicativo" non e' generale,
applicabile com'e' solo ad unix ed al DOS, quindi, a meno che tu non ti
riferissi esplicitamente a quei due OS, ma la intendessi come generale, e'
scorretta.
Ed il fatto che su alcuni OS sia un applicativo non significa che sia la
cosa migliore.
Fabio Alemagna

 spesso, l'argomento di questo NG).
Affermazione senza senso... linux, come sistema operativo, deve possedere
una shell, che sia grafica o testuale poco importa, ma se la voglio
grafica, allora posso anche permettermi di dire che qelle ra le quali
posso attualmente scegliere non mi soddisfano, e nessuno mi puo' dire che
linux e' un OS e quindi non ha bisogno di una GUI.
Fabio Alemagna

 cosa migliore.
...sarebbe comunque meglio concepirla come tale.
In ogni buon design bisognerebbe avere una certa
strutturazione.
Pur potendo (la GUI) essere parte dell'OS, dovrebbe comunque
esserne una parte ben separata, tanto da essere concepibile
come applicativo a parte (anche se magari non lo e`).
Vi sono molteplici ragioni per cui preferire la modularita`,
per cui parlare di GUI relativamente ad un OS non dovrebbe
essere un argomento facilmente accettato.
La GUI dovrebbe sempre essere "staccabile" e mai radicata
dentro l'OS.
Ovviamente le cose vanno fatte "cum grano salis", ed in
questo senso non mi sento affatto di dire che X + GNOME
(o simile) siano quantomeno decenti... ;-)
bye,
-- 
  Piergiorgio Sartor

 linux e' un OS e quindi non ha bisogno di una GUI.
No, non ha bisogno di GUI, dato che di "G" "U" "I", l'unica
cosa che (forse) serve e` la "I" di "I"nterface, mentre
"G"raphical e "U"ser non e` detto affatto che servano.
bye,
-- 
  Piergiorgio Sartor

 dentro l'OS.
Dunque... mettiamo che la macchina sulla quale gira il mio OS ha solo un
display grafico. Mi stai dicendo che su questa macchina devo ridurmi ad
emulare una modalita' testuale solo perche' qualcuno crede che sia la cosa
migliore?
Sarebbe una limitazione artificiale, senza senso. Dovresti dimostrare che
e' la cosa migliore. Ti senti di farlo?
Fabio Alemagna

del sistema operativo.
Bene. Allora la sostituisci con altro. Quindi, utilizzi altro per
svolgere le funzioni della shell, giusto? Mi sta bene. Ma da qui a
dire che non sia necessaria nessuna shell, o applicativo adatto come
dici tu, mi pare ci siano difficoltà. 
Non sono un programma, io. Che faccio, vado a colpi di chiamate di
funzione sul Gcc?  :) 
Te lo chiedo perchè quello che dici contrasta con tutto quello che
fin'ora ho letto. 
Gianni    

 "G"raphical e "U"ser non e` detto affatto che servano.
Appunto, *non e detto*, ma se IO lo dico perche' a ME serve allora nessuno
mi puo' dire che sbaglio.
Fabio Alemagna

 e' la cosa migliore. Ti senti di farlo?
Non impongo nessuna limitazione, anzi, a me pare esattamente il
contrario, cioe` avere la GUI come applicativo sia definitivamente
l'eliminazione di ogni limitazione, mentre averla nell'OS sia
alquanto limitante.
E, comunque, si, mi sento anche di farlo, dato che mi piace
la dialettica sofista :-)
bye,
-- 
  Piergiorgio Sartor

 fin'ora ho letto.
In che senso?
bye,
-- 
  Piergiorgio Sartor

 alquanto limitante.
Ho detto che sarebeb una limitazione emulare una modalit'a testo su una
macchian con un display solo grafico.
Fabio Alemagna

 mi puo' dire che sbaglio.
Se a te serve la GUI, questo non vuol dire che in generale
la GUI serva all'OS, serve a te, non all'OS in quanto tale.
In questo senso la GUI e` un applicativo.
bye,
-- 
  Piergiorgio Sartor

 la GUI serva all'OS, serve a te, non all'OS in quanto tale.
Non ho mai parlato in generale, ho solo detto che dire "linux non ha una
gui decente" puo' essere opinabile, ma di certo non e' confutabile dicndo
che "linux non ha bisogno di una gui" che, pur essendo vero, non ha nulla
a che vedere con l'affermazione che si intende confutare.
Fabio Alemagna

 Esattamente, ed in quel caso si utilizza un OS che giri anche senza GUI.
Quindi mi serve un OS che non abbia la GUI, quindi la GUI
non fa parte dell'OS, in questo caso.
Dato che questo caso contiene comunque il caso desktop, direi
che e` sufficientemente generale per dire che, in generale,
la GUI non deve far parte dell'OS.
bye,
-- 
  Piergiorgio Sartor

 a che vedere con l'affermazione che si intende confutare.
Ha a che vedere con il fatto che Linux (OS) puo` o non puo` avere
una GUI (applicativo, sicuramente nel caso Linux).
Cioe` non si puo` confutare la bonta` o meno di Linux (OS), affermando
che uno dei suoi (tanti) applicativi non e` decente.
Questo era il succo.
Come dire: "Linux non ha una suite office decente", questo non
c'entra nulla con la qualita` di Linux in quanto OS.
Oppure: "Linux ha un web server ottimo", questo non c'entra
ancora nulla con la qualita` di Linux in quanto OS, dato che
lo stesso web server gira su (quasi) tutti gli OS disponibili.
bye,
-- 
  Piergiorgio Sartor

In che senso?
 
Nel senso che, dai libri su cui studio all'università fino a, che sò
io, gli Appunti di informatica Libera, un sistema operativo è
genericamente definito dalle componenti kernel + shell + altri
programmi applicativi. Ma, in effetti, hai ragione. Più si scende
nella particolarizzazione e più il concetto diviene astratto, quasi
obsoleto. Però questo non l'avevo considerato. Io mi ero posto un
termine di paragone per capire il tuo ragionamento, diciamo Linux. E
ho pensato: ok, Piergiorgio prende e taglia la shell. Poi vuole usare
un applicativo, come il DB. E allora si serve del necessario e lo usa.
Ma se poi vuole far altro? Io contemplavo questa possibilità, tutto
qui!
Perdonami per l'eventuale confusione nell'esporre stì concetti.
Gianni

 qui!
Ovviamente se devo fare altro sono fregato (nel caso DB).
Distinguerei tra OS "generale" ed utilizzo "generale" dell'OS.
Tu dici: "ho una macchina, voglio un OS che mi consenta
fare il maggior numero di cose possibili".
Io dico: "ho un OS che, in circostanze diverse, deve poter
fare il maggior numero di cose possibili, non necessariamente
contemporaneamente"
Il mio esempio vuole semplicemente mostrare un caso particolare,
che _deve_ essere coperto dal caso generale (ovvio no?), in cui
il concetto di "shell", come estensione del kernel per avere un OS,
porta a qualcosa che razionalmente non e` piu` accettabile solo
come OS, ma come OS+applicativo.
Spero, nonostante l'eccessiva astrazione, che il mio pensiero
sia stato chiarito...
bye,
-- 
  Piergiorgio Sartor

 parte dell'OS in senso stretto...
Ora ti sei spiegato :-)
--
Medaglia, medaglia, medaglia....
Mutley

 Ora ti sei spiegato :-)
Manco mal... :-)
bye,
-- 
  Piergiorgio Sartor

contemporaneamente"
Hai in mente di non dover avere una shell *unica*, universale per
quell'os e tutto-fare ma diverse, con capacità di assolvere compiti
più specialistici. 
Ecco che, a questo punto, la mia *preoccupazione* per il desktop
sarebbe risolta da una shell 'casalinga', con funzioni simili a quelle
già esistenti sui desktop ora. Se poi avessi bisogno di lavorare sul
famoso DB, usufruendo anche di altri applicativi tipici di 
quell'ambiente, avvii una shell diversa dalla precedente, che tiene
conto di diverse esigenze. 
Tutto questo perchè sono strutturate e magari si comportano come degli
applicativi, nel senso che lavorano ad un livello più alto rapportato
allo stato attuale delle cose.  
Qualcosa del genere?  :)
Gianni

 Su di un personal si, ma questo e` limitativo, ripeto.
Certo, un conto e' parlare di OS per PC, un altro e' parlare di OS in modo
generico.


 allo stato attuale delle cose.
Direi che la complessita` dei sistemi attuali necessita
una chiara distinzione di ruoli (il che sembra un
discorso politico, lo so...).
Certo, potrebbe essere solo una questione di dare
gli stessi nomi alle stesse cose :-)
Tutto il discorso e` piuttosto filosofico...
bye,
-- 
  Piergiorgio Sartor

 generico.
Certo, vi sono varie categorie.
Ritornando a Linux, questo puo` essere OS da server,
in cui la GUI non serve, ma solo una UI.
Oppure desktop, in cui la GUI e` fortemente raccomandata.
Oppure girare in sistemi embedded, in cui la UI potrebbe
non esistere od essere qualcosa di totalmente diverso
da quello che comunemente si pensa (un manopola, per esempio).
E` chiaro che, avendo questa flessibilita` e volendo
anche essere scalabile, si deve porre la GUI, in quanto
"G"raphical, ad un livello diverso da quello di OS,
deve necessariamente essere un modulo SW al pari
di altri task od applicativi o processi o come li
vuoi chiamare (sono certo che il termine "applicativo"
puo` essere fuorviante, ma su questo si puo` sempre
fare chairezza in caso di dubbi).
Questo per mantenere la "generalita`" dell'OS, cosi`
come Linux pretende di fare.
Certo, altri potrebbero avere altre idee...
bye,
-- 
  Piergiorgio Sartor

 generico.
Certo, vi sono varie categorie.


migliore?
No, devi emulare una modalita` testuale perche` in caso di problemi con
il sistema operativo e` molto piu` semplice tirare su una console
testuale che un ambiente grafico.
E senza console testuale non c'e` modo di stampare messaggi al boot
prima che l'ambiente grafico sia attivo.
Esempio: ogni sun, i PC tra cinque anni.
I mac non contano, visto che loro hanno un pezzo di OS in ROM (e quelli
moderni con openfirmware di sicuro emulano una modalita` testo).
-- 
ciao, | "You're one of those condescending Unix computer users!"
Marco | "Here's a nickel, kid. Get yourself a better computer"  -- Dilbert
      | (Ri)scoprire fidonet: 
http://bbs.bofh.it

 moderni con openfirmware di sicuro emulano una modalita` testo).
Piu' che altro ha senso poter *stampare* testo, proprio ai fini del debug,
ma una intera console ha poco senso.
Fabio Alemagna

 la cosa migliore.
Dipende dall'uso. 
Certo, se non e` scollegata dal kernel, la stabilita` va a puttane.
-- 
Renato "Hitman" Salzano - 
http://spazioweb.inwind.it/hitman/
 
e-posta : sonicblast (at) 
inwind.it
 / Fan di Helena Velena 
"Qualche volta sogni, anima, fantasia e realta` si mescolano, e i loro
 confini sfumano fino a sparire. E mi e` piaciuto" (Io, riflettendo)

 dire che linux e' un OS e quindi non ha bisogno di una GUI.
Ci sono casi in cui una GUI e` solo un peso inutile.
Linux soddisfa questi casi, altri SO no.


 troppo (vedi Win, ma è per l'appunto un caso limite...brrr...)....
Troppo limite. Win in realta` non e`  un OS generico, da questo punto di
vista.


 funzione sul Gcc? :)
Dimentichi i casi  in cui un computer non interagisce  mai con un essere
umano, ma solo con altri apparati elettronici e/o altri computer.


 
Diciamo che se è nel kernel ed è scritta male la stabilità ne risente.
Diciamo che GUI nel kernel== _potenziale_ instabilità
Ovviamente se è fuori dal kernel il problema è risolto a monte.
Anche se una GUI instabile rende comunque inutilizzabile una workstation 
(e il fatto di sapere che i demoni e i processi in background funzionano 
a meraviglia non è di gran sollievo per chi ha perso qualche ora di 
lavoro...).   
-- 
Valter Minute
min...@inwind.it
 (the reply address of this message is invalid)

prima e  di riavviare dopo)
       ^^^^^^^^^^^^^^^^^^^^
Basta aggiustare inittab e dare telinit :-)
Leonardo
-- 
Microsoft Outlook: il primo news reader con supporto messaggistica RAID 1.

ma una intera console ha poco senso.
Secondo te cosa e` piu` semplice implementare?


 Secondo te cosa e` piu` semplice implementare?
Il poter stampare testo, ovviamente. Di una intera console non me ne
faccio nulla e sarebbe solo uno spreco di risorse. AROS, per esempio, usa
la metodologia da me descritta.
Fabio Alemagna

 Linux soddisfa questi casi, altri SO no.
Quello che volevo ribadire e' che se io sto contemplando solo i casi in
cui la GUI e' indispensabile non mi si puo' dire che linux non ha bisogno
di GUI quando faccio notare che le gui attualmente disponibili per linux
non sono soddisfacenti. Non si puo' perche' *nel contesto* di cui si
discute la gui *e'* essenziale.
In altre parole, se io dico che linux come desktop non e' pronto, non ha
alcun senso rispondere "sě,  pero' come server e' una bomba".
Fabio Alemagna

faccio nulla e sarebbe solo uno spreco di risorse. AROS, per esempio, usa
Allora non sarebbe una GUI completa ma solo una finta.


 nulla.
Uhm, un interessante spunto di riflessione.
La shell e` un processo o task che fa da interfaccia tra
il kernel ed il mondo esterno, pero` deve usare i driver
del kernel, ovviamente.
Cioe` legge dei dati usando uno o piu` driver del kernel,
li trasforma in qualche modo e scrive dei dati usando uno
o piu` driver del kernel.
Fin qua abbiamo una descrizione molto generica di shell,
infatti, a questo punto, qualunque processo che fa I/O
e` una shell, dato che tutti i processi che fanno I/O si
comportano nel modo descritto sopra.
Vi sono diverse domande che mi vengono in mente, senza
polemica alcuna:
E` possibile avere piu` di una shell contemporaneamente?
Cosa distingue la shell da, ad es., gcc (che fa esattamente
la stessa cosa)?
Vi e` un qualche specifico I/O che solo e soltante la
shell fa per cui la shell e` tale e solo e soltanto essa?
Non saprei, ma mi pare che ancora manchi qualcosa...
Comunque e` solo una discussione filosofica estiva :-)
bye,
-- 
  Piergiorgio Sartor

 Basta aggiustare inittab e dare telinit :-)
Siamo prossimi al contagio totale!!! :-)
bye,
-- 
  Piergiorgio Sartor

 shell possibile).
Pero` Fabio ha generalizzato il concetto di shell,
se ho ben capito, secondo la sua definizione,
init e` una shell.
Potrebbe anche avere ragione, in questo senso si dovrebbe
cambiare init, cosa che dovrebbe comunque essere possibile,
anche se non auspicabile...
bye,
-- 
  Piergiorgio Sartor

 bye,
bye
-- 
David Mugnai
God is real... unless declared an integer.

 o quant'altro)
Forse non mi sta piu` cosi` bene, avrei una definizione
piu` stretta o diversa.
Questa, cioe` quella di applicativo che interfaccia il
kernel con il mondo esterno, e` la definizione di ogni
applicativo, proprio in quanto tale.
Ogni applicativo, alla fine, fa questo.
Io proporrei l'esatto opposto, cioe` shell e` un processo
(o task od applicativo) che NON si interfaccia con il
mondo esterno, ma solo con quello interno, cioe` offre
un layer in piu` tra kernel ed i processi (o task od applicativi),
interfaccia il kernel con gli applicativi.
In questo contesto, init (di Unix) diventa una shell e
la shell (bash, sh, etc.) non e` piu` una shell..!
Attenzione: un applicativo che si interfaccia con altri
applicativi (anche se passando per il kernel) non
soddisfa a questa definizione.
bye,
-- 
  Piergiorgio Sartor

 ci deve girare un applicativo, almeno...
No no. Il fatto che l'unico applicativo che gira sia la shell, e quindi sia
parte integrante dell'OS, non lo fa decadere dallo status di "applicativo".
Un OS ha bisogno di una shell, altrimenti sarà pure un _sistema_, ma di
certo non è _operativo_.
Saluti.
--
Wilmer Ricciotti
wi...@bigfoot.com

 certo non è _operativo_.
Perche`?
Cioe` tu riferisci il termine "Sistema Operativo" a
tutta la macchina, cioe` a tutto il sistema, dal kernel
fino all'applicativo utente?
Continua a sfuggirmi questa distinzione tra shell (come
componente fondamentale dell'OS) ed applicativo generico.
Direi che la definizione di OS, in se, mi sfugge a questo
punto, cioe` relativamente, ad es., a w95 oppure a VxWorks.
bye,
-- 
  Piergiorgio Sartor

 shell fa per cui la shell e` tale e solo e soltanto essa?
E' il *significato* di quell I/O che conta, non il fatto che sia I/O.
Fabio Alemagna

 Allora non sarebbe una GUI completa ma solo una finta.
Be', allora tutti quelli che usano AmigaOS, AtheOS, BeOS, AROS MacOS e
tanti altri non sanno di stare utilizzando una gui che in realt'a gui non
e'...
Fabio Alemagna

 20 goto 10
Sniff, che malinconia: mi ricorda la shell degli home computer, il BASIC
;'-)


 la shell (bash, sh, etc.) non e` piu` una shell..!
In questo contesto qualsiasi programma e' una shell 
poiche' un programma per funzionare non ha bisogno di un altro
starto software, ma si interfaccia direttemente con il
kernel, attraverso le sue api
-- 
David Mugnai
Press any key to continue or any other key to quit...

 kernel, attraverso le sue api
Si, ma OS cos'e` a questo punto?
Tutto il sistema in toto?
Oppure OS == kernel?
bye,
-- 
  Piergiorgio Sartor

 E' il *significato* di quell I/O che conta, non il fatto che sia I/O.
Cioe` sarebbe un SW che mappa chiamate del kernel in
altre chiamate e rende queste disponibili verso l'esterno,
cioe` verso altri programmi o dispositivi?
bye,
-- 
  Piergiorgio Sartor

 cioe` verso altri programmi o dispositivi?
Piu' o meno...
Fabio Alemagna

 componente fondamentale dell'OS) ed applicativo generico.
La shell è un applicativo. Non tutti gli applicativi sono shell (ma
moltissimi possono esserlo, se si configura il sistema in maniera apposita).
L'applicativo shell deve essere concepito come parte del sistema operativo,
altrimenti come fa a essere operativo?


 altrimenti come fa a essere operativo?
Consideriamo pSOS, questo e` definito OS, eppure nella
maggior parte delle sue applicazioni il concetto di "shell"
non esiste, almeno se considero le definizioni fin qui esposte.
Se hai qualche definizione di "shell" che possa coprire
tutti i casi, fammi sapere, perche` io non mi ci
raccapezzo piu`...
bye,
-- 
  Piergiorgio Sartor

 Piu' o meno...
OK e nei casi embedded, in cui parte un applicativo,
direttamente, il quale NON ha come funzione quella
di mappare chiamate del kernel.
Ad es. un set top box con browser.
Di solito ci gira un OS (almeno lo definiscono tale), ma
l'utente vede solo il browser, il quale non mappa nulla
del kernel (almeno non in maniera diretta o cosciente),
cioe` non rende disponibili interfaccie del kernel all'esterno.
Usa direttamente il kernel per eseguire le sue funzioni e
realizzare un interfaccia utente, ma non con il kernel.
Potrei anche considerare uno strumento di misura, il
quale ha un OS RT, alcuni task che effettuano acquisizione
dati, processamento e visualizzazione, ma nessuno fornisce,
esplicitamente, interfacce per il kernel.
In questi casi bisogna adattare un po' le definizioni,
cosa sia il kernel e` piuttosto chiaro, ma cosa sia l'OS
lo e` un po' meno, dato che non esiste una shell in senso
cosi` esplicito, tutto il concetto di shell e` embedded
nei vari processi (non in uno solo, tra l'altro).
Insomma nonostante si parli comunemente di OS, il layer
shell non e` piu` cosi` evidente, questo mi porta a pensare
che si debba rivedere qualcosa.
bye,
-- 
  Piergiorgio Sartor

 non esiste, almeno se considero le definizioni fin qui esposte.
Be', non conosco pSOS, ma tra i suoi applicativi dev'esserci qualcosa che si
interfacci con l'esterno o con altri applicativi. Il mio dubbio era semmai
un altro... come considerare un sistema operativo in cui si facciano girare
più applicativi con funzioni di shell, magari contemporaneamente? Forse
utilizzo un sistema operativo diverso a seconda dell'applicazione che
utilizzo come shell... oppure posso dire di avere più shell attive
contemporaneamente.
E se aggiungessimo alla definizione di shell il fatto che deve permettere di
lanciare altre applicazioni? In tal caso si potrebbero avere anche sistemi
operativi senza shell (nel senso che non c'è un'interfaccia che permetta di
avviare altri programmi), ma non si potrebbe ridurre comunque l'OS al solo
kernel: OS=kernel+shell OPPURE kernel+applicativo.
Ma in fondo è solo una questione filosofica. Il significato delle parole
risiede nell'uso, per cui spesso è difficile dare una definizione precisa
con altre parole...
Saluti.
--
Wilmer "Wittgenstein" Ricciotti
wi...@bigfoot.com

 In questo contesto qualsiasi programma e' una shell
[..]
Non vorrei sembrare troppo semplicista, ma, IMHO, la shell non e' altro
che un programma che realizza un interfaccia per lanciarne altri.
-- 
Sostituisci nospam con daniel.kobza per rispondere via e-mail

 Basta aggiustare inittab e dare telinit :-)
Giusto. 
/me segna un'altro trucchetto da sysadmin esperto :-)
-- 
Renato "Hitman" Salzano - 
http://spazioweb.inwind.it/hitman/
 
e-posta : sonicblast (at) 
inwind.it
 / Fan di Helena Velena 
"Qualche volta sogni, anima, fantasia e realta` si mescolano, e i loro
 confini sfumano fino a sparire. E mi e` piaciuto" (Io, riflettendo)

 con altre parole...
Avevo gia` premesso che questa era una discussione
filosofica estiva :-)
bye,
-- 
  Piergiorgio Sartor

 che un programma che realizza un interfaccia per lanciarne altri.
E se non ne lancia altri? Ma fa tutto da se?
Non e` piu` una shell e quindi non abbiamo piu` un OS?
bye,
-- 
  Piergiorgio Sartor

 esplicitamente, interfacce per il kernel.
Ecco, qua magari una shell manca...


 
Già. Ma se la gui non parte sei a piedi.
--
Au revoir.
Lele...

 ("int main(void){while(1);}" in AtheOS è un DoS in piena regola)
 
E ciò non è bello affatto...
-- 
Au revoir.
Lele...

 
Nel caso linux non trovi init in /bin/init nel root filesystem allora avvia
/bin/sh. Se non la trova, allora e solo allora, esordisce con un bel 
kernel panic...
(Provato sulla mia pelle facendo un dischetto di emergenza... :-)
Quindi OS == linux+init oppure OS == linux+sh
Diciamo che sh è una soluzione di ripiego (come se il kernel chiedesse 
all'utente
"Che devo fare?", solo perchè la soluzione ideale non era funzionante)
Come definizione di OS, linux+init può essere un buon compromesso... :-)
-- 
Au revoir.
Lele...

 o quant'altro)
Allora la shell puņ essere inutile. :-)
Poni un programma che si interfaccia direttamente con il kernel 
(semplicemente
bypassa la libc) e che non riceve input dall'utente.
Vuoi un esempio sparato al volo? :-)
Un programma di utilitą che controlla i banchi ram cercando settori 
difettosi.
O che faccia lo stesso sui dischi. O su qualsiasi altra cosa...
Utili se devo testare i prodotti che installo...
-- 
Au revoir.
Lele...

 
Nooooo, non ricominciamoooo.... :-)
Scusa lo sfogo, ma una affermazione ha già scatenato un thread 
abbastanza lungo su
dove finisste il kernel e cominciasse l'OS...
Cmq, la gui è nel kernel...
IMHO, moolto negativo.
-- 
Au revoir.
Lele...

Quindi OS == linux+init oppure OS == linux+sh
Assurdo. Allora OS == linux+programmadedicato, e questo non ha senso.
init e la shell funzionalmente sono programmi esattamente uguali agli
altri.
-- 
ciao, | "You're one of those condescending Unix computer users!"
Marco | "Here's a nickel, kid. Get yourself a better computer"  -- Dilbert
      | (Ri)scoprire fidonet: 
http://bbs.bofh.it

 altri.
beh, OS vuol dire sistema operativo, se linux senza quei componenti
e` inoperativo (kernel panic? io non ho mai provato a torglerli),
allora non svolge la funzione di farti funzionare la macchina.
--
ciao, Mirco.
[ Icq#:51640305 ] [ 
http://spazioweb.inwind.it/mmos2/
 ]

binario.
Ovviamente no, serve come minimo una libc implementata con le system
call native o un layer di system call compatibili da usare con la libc
originale.


 Ecco, qua magari una shell manca...
Potrebbe comunque esservi un'interfaccia utente, ma non
con il kernel, semplicemente un task che prende dell'input,
magari da bottoni, e controlla gli altri task settando dei
parametri, magari globali.
bye,
-- 
  Piergiorgio Sartor

allora non svolge la funzione di farti funzionare la macchina.
E` perfettamente operativo, i sistemi embedded spesso non usano init.


 E` perfettamente operativo, i sistemi embedded spesso non usano init.
ma le versioni embedded sono la stessa che compilo io?
E in ogni caso, forse avranno altro codice per fare/servire l'HW su cui sono montati.


 
Già, ma non penso che inglobino tutte le funzionalità nel kernel.
Per tale motivo ci sarà un applicativo che girerà sopra al kernel.
Il quale può essere init, sh o un webserver...
A dir la verità il webserver nel kernel c'è (tux, khttpd) ma senza /bin/init
o /bin/sh, ho idea che linux vada in panic avvisandoti del problema...
-- 
Au revoir.
Lele...

 
Il concetto di SO come kernel+altro è una convenzione, null'altro che 
una mera
convenzione. Affinchè qualcosa sia operativo, è necessario solo il 
kernel, basta
che quest'ultimo inglobi le funzionalità dell'applicativo :-)
Il ragionamento di SO come qulcosa che sia operativo può andar bene solo 
per i
microkernel, in cui il kernel è capace solo di poche e insufficienti 
operazioni.
Il pensare ad un kernel monolitico che include un webserver può solo 
introdurre
complicazioni, in quanto ingloba l'applicazione che è ben distinguibile
logicamente dal kernel stesso. I microkernel, invece, rispecchiano il 
massimo grado
di frammentazione logica...
-- 
Au revoir.
Lele...

486 sarebbe troppo lento?
"hanno"? ti sfugge che AtheOS è un "one-man project", come e più di 
Linux

 che quest'ultimo inglobi le funzionalità dell'applicativo :-)
In quel caso, tuttavia, non lo puoi considerare solo kernel. Se non altro
perché se parli di un "nucleo" fai capire implicitamente che attorno ad esso
c'è qualcosa.
Saluti.
--
Wilmer Ricciotti
wi...@bigfoot.com

E in ogni caso, forse avranno altro codice per fare/servire l'HW su cui sono montati.
?
-- 
ciao, | "You're one of those condescending Unix computer users!"
Marco | "Here's a nickel, kid. Get yourself a better computer"  -- Dilbert
      | (Ri)scoprire fidonet: 
http://bbs.bofh.it

Già, ma non penso che inglobino tutte le funzionalità nel kernel.
Infatti c'e` il kernel e il programma applicativo specifico, ma niente
init.


 operazioni.
Ancora mi manca questa distinzione: cosa sono "operazioni
insufficienti",
a cosa poi "insufficienti?
bye,
-- 
  Piergiorgio Sartor

 
Un microkernel solitamente passa solo i messaggi tra i vari moduli posti al di 
sopra di esso. Se questi non ci sono, che messaggi passa il kernel? :-)
-- 
Au revoir.
Lele...

 Linux
Ad essere sinceri, sě me ne ero del tutto scordato. Pensavo che col tempo 
qualche appassionato si fosse aggregato, mentre dalle tue parole la situazione 
non č cambiata... :-(
 
Ciň nonostante, io continuo a preferire SO che abbiano qualche idea in piů che
mettere la gui nel kernel.
VSTa potebbe essere considerato un buon esempio...
-- 
Au revoir.
Lele...

 ?
il kernel e basta su un sistema embedded, come su una macchina normale, e la base
per i programmi. Su una macchina embedded, gireranno prg per tale macchina.
Cmq, quello che volevo arrivare a dire, e` che sulla debian che sta sul mio server
io non ho il "kernel per sistemi embedded", il mio sulla macchina e` in qualche modo "dipendente da programmi" per essere
operativo.
Il fatto che con la modifica di anche una sola riga di codice (da quello che ho io)
il sistema parta senza init o sh [*], e` una cosa diversa.
[*] okkio, come ho scritto precedentemente, io non ho verificato se sia vera
questa cosa per cui il mio kernel non vada senza init e sh.
--
ciao, Mirco.
[ Icq#:51640305 ] [ 
http://spazioweb.inwind.it/mmos2/
 ]

 sopra di esso. Se questi non ci sono, che messaggi passa il kernel? :-)
Si, in un uK, ma in un kernel normale come siamo messi?
bye,
-- 
  Piergiorgio Sartor

 il sistema parta senza init o sh [*], e` una cosa diversa.
il punto e' che se non e' init o sh dovra' essere qualche altra cosa, e
non c'è bisogno di cambiare nessuna riga di codice, basta passare il
parametro init=<tuo programma> al kernel.
Quel "qualche altra cosa" e' la tua nuova shell.
Fabio Alemagna

 Quel "qualche altra cosa" e' la tua nuova shell.
La domanda e` sempre la stessa: se quella altra cosa
NON si propone come interfaccia con il kernel, ma come
applicativo o task che svolge le sue funzioni, si puo`
sempre parlare di shell?
bye,
-- 
  Piergiorgio Sartor

 sempre parlare di shell?
parli di programma :)


 parli di programma :)
Uh, cioe`?
bye,
-- 
  Piergiorgio Sartor

 Uh, cioe`?
se una cosa non e` una shell allora non parli di shell. Anche se pure una shell
e` un programma:)
La shell e` una qualcosa che ti permette di operare con la macchina. Possono
essere shell tutti i programmi che ti consentono di interagire con la macchina tramite
le periferiche di input (umanamente usabili) quali mouse, tastiera, penna ottica, voce...


 le periferiche di input (umanamente usabili) quali mouse, tastiera, penna ottica, voce...
Dunque, per prima cosa, che vuol dire "interagire con la macchina".
Ad es. Word e` una shell?
Non ha come scopo primario quello di interagire con la macchina,
d'altro canto usa i driver del kernel per fare I/O, non si appoggia
(necessariamente) su di una shell.
A meno che tu non definisca "shell" tutto il sottosistema GUI
dell'OS, in questo caso, pero`, tale sottosistema da solo non
consente di fare un bel niente, senze un altro SW che lo usi,
tipo Word appunto.
Quindi la shell diventa Word+GUI, il che non credo sia
molto accettabile, forse...
Seconda cosa: come la mettiamo con quei sistemi (embedded) che
forniscono dei servizi, basati su OS, ma non mostrano estrernamente
alcuna funzionalita` del kernel.
In realta` potrebbero non dover neanche interagire con esseri umani...
La questione e` sempre la stessa, cioe` come differenziare la
shell, nel senso di interfaccia, dai driver e da altri applicativi.
bye,
-- 
  Piergiorgio Sartor

 shell, nel senso di interfaccia, dai driver e da altri applicativi.
hmm, vedi, io sono entrato in questo thread dicendo quello che secondo me e`
un sistema operativo. Per me cercare di categorizzare tra shell e programmi non ha senso
per il semplice fatto che la shell e` un programma... ad es. io sotto dos usavo come
shell il norton commander... oppure win.com... non facevo partire il 
command.com
.
La stessa cosa la puoi fare in praticamente tutti i sistemi operativi attuali.
Per me un sistema operativo (come ho gia` scritto in un altro post) e` fatto anche di
programmi, che siano uno o 200 dipende dallo scopo a cui deve essere adibito tale SO.


 programmi, che siano uno o 200 dipende dallo scopo a cui deve essere adibito tale SO.
OK, quindi secondo te OS == kernel + programmi
Allora in questo NG noi discutiamo piu` di "kernel"
che di "OS"?
bye,
-- 
  Piergiorgio Sartor

 di cui si discute la gui *e'* essenziale.
A  parte che  trovo XFce  la  migliore GUI  su  cui ho  lavorato (ma  de
gustibus),  sei  anche tu  che  stai  mettendoti  in un  caso  specifico
particolare.
-- 
Renato "Hitman" Salzano - 
http://spazioweb.inwind.it/hitman/
 
e-posta : sonicblast (at) 
inwind.it
 / Fan di Helena Velena 
"Qualche volta sogni, anima, fantasia e realta` si mescolano, e i loro
 confini sfumano fino a sparire. E mi e` piaciuto" (Io, riflettendo)

 che di "OS"?
nel NewsGroup? Oddio, non ricordo tutti i thread a memoria...


 nel NewsGroup? Oddio, non ricordo tutti i thread a memoria...
OK, a volte discutiamo piu` di altro... :-)
bye,
-- 
  Piergiorgio Sartor