Newsgroup: it.comp.os.dibattiti
Titolo: La storia del free/open source software

Ciao a tutti,
per un esame(Storia dell'Informatica) mi trovo a dover scrivere un
approfondimento sulla storia del FOSS.
E' un argomento per la cui trattazione si rischiano, a mio parere:
1) Cadere nella banalità. Dare un messaggio superficiale del tipo "Lode a
te, o Stallman, per la GPL". Non è certo mia intenzione...
2) Scrivere una mera cronologia. Non mi va.
3) Su un newsgroup di dibattito sui sistemi operativi corro il rischio di
scatenare un mega flame. Ho lurkato abbastanza per sapere che è
un'eventualità da non escludere. Però dai flame spesso nasce qualche spunto
utile.
Il taglio che intenderei dare sarebbe quello di tessere le lodi del
movimento open source su alcuni aspetti(Legge di Linus: dato un numero
sufficiente di occhi, nessun bug è introvabile; nuove opportunità di
sviluppo; chiunque può suggerire qualcosa agli sviluppatori del proprio
progetto preferito o diventare a sua volta sviluppatore) e criticare alcuni
aspetti(la facilità estrema con la quale progetti piccoli eseguano continui
fork! Ma anche Stallman raditi... etc).
Sono qui, dunque, per chiedere a voi: leggendo un articolo sul FOSS e la sua
storia, di quali temi vorreste leggere? E con quale taglio?
Elenco brevemente, ma in ordine sparso quali sarebbero i punti che
attualmente ho intenzione di trattare:
* In principio era open source. Il software proprietario è arrivato dopo,
cfr. lettera aperta di un certo William Henry Gates III, nel 1977, ad una
mailing list di hobbisti del software.
* Richard Stallman. Nel suo piccolo, un grande. Ma con qualche tratto che
rasenta il fondamentalismo. Aspetto ancora GNU/Hurd. In fondo sono
ottimista.
* Davide batte Golia. Linus vs Tanenbaum. "Io ti avrei bocciato", "Si, ma il
mio os funziona". Tanenbaum scrive che i due abbiano in seguito fatto
amicizia. Da cultore dei sistemi operativi, ritengo che i microkernel
meritino attenzione.
* La cattedrale ed il bazaar. Modelli di sviluppo nell'OS.
* Open source come modello di business. Non solo filantropia, ma anche
guadagno per aziende che dalla comunità prendono e alla comunità danno.
IBM, Sun, [inserire altre].
* Unix si evolve. Non elencherò sistematicamente la diaspora da Unix System
V in poi, ma dedicherò giusto un paragrafo, per arrivare a Linux che cerca
popolarità sul mondo desktop. KDE. Gnome che nasce perché KDE usava
librerie non libere, per poi cercare un'integrazione con Mono. Della serie,
anche nell'OSS esistono contraddizioni.
In fine, fate finta che questo articolo sia il vostro software preferito.
Cosa ci vorreste?
Grazie a tutti. So che ne vedremo delle belle.

 anche nell'OSS esistono contraddizioni.
Beh ma ci sono anche casi di reintegrazioni: recentemente c'è la gradita
riunificazione tra compiz e beryl, e se vogliamo anni fa ci fu quella tra
il vecchio gcc e quello "forkato" (mi sfugge il nome).
Fare fork è diritto sacrosanto, soprattutto quando il mantainer principale
del programma in questione c'ha la testa dura e non ci sente da nessun
orecchio. Anche Stallman qui casca a fagiolo: prova a cercare informazioni
sul fork di XEmacs da GNU Emacs.
Riguardo mono, i fatti stanno in modo leggermente diverso, se vogliamo.
Miguel de Icaza si prese la briga di reimplementare .NET perché per lui
rappresentava l'unico modo per evitare la continua riscrittura di librerie
di funzioni sotto linguaggi diversi (Python, C++, etc).  Se c'è già,
perchè reinventare l'acqua calda? Era questo il motivo (*). Poi abbiamo
visto che alla fine nessuno si è preso la briga di riscrivere niente in C#
e co., a parte qualche nuova applicazioncina stupida o mostri tipo Beagle
o Zenworks.
(*) La contraddizione se vuoi sta qui: perchè riscrivere tutto un desktop
manager (Gnome) e non solo fare una versione libera delle QT?

harlock wrote:
Non riporto nulla, ma ti scrivo che condivido ogni spunto che mi hai dato.
Grazie mille!

 desktop manager (Gnome) e non solo fare una versione libera delle QT?
non ti seguo... anche perche' non so se' e' nato prima l'uovo o la 
gallina. A occhio direi che si sono evoluti parallelamente, insieme.
boh ... forse mi sfugge qualcosa.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 ... forse mi sfugge qualcosa.
anche questa storia dei "regression bug" e' un tantino discutibile.
In sostanza, si dice, che chi mangia fa molliche: questa e' la 
conseguenza dei regression bug.
Per evitarli quindi ci sono due metodi:
1) non mangiare
2) pulire dopo mangiato
Il primo metodo - diciamo la verita' un po' scherzosamento - e' bsd style.
Il secondo metodo consiste invece nel ripetere test gia' eseguiti, 
poiche' nuove feature introducono bla, bla .... insomma si tratta di 
misurare bene gli sforzi e gestire bene lavoro e risorse disponibili.
O qualcuno vuole dire che tutto dipende dal fatto che Linus e' inetto e 
De raadt sarebbe intelligente?


 manager (Gnome) e non solo fare una versione libera delle QT?
Per rispondere alla domanda dobbiamo fare un paio di considerazioni:
1) Nel 1996, quando e` nato KDE, le uniche librerie disponibili erano QT
e Motif (nonche` Xt). Data questa situazione, Matthias Ettrich (creatore
del progetto) ha fatto una scelta decisamente sensata e (per i tempi)
rivoluzionaria: perche` utilizzare qualcosa di complesso o reinventare
la ruota quando vi e` una libreria liberamente utilizzabile e semplice
(QT)?
2) Fino al 1997 le GTK (le librerie librerie su cui si basa GNOME) erano
parte indissolubile di Gimp. Lo scorporo vero e proprio (e quindi
l'effettivo utilizzo di tali librerie per scopi differenti dall'essere
la base del famoso programma di fotoritocco) lo si ha solo con GNOME.
Praticamente, il nodo cruciale della questione si aggira attorno ad una
data fatidica: il 1997. In quel periodo si puo` dire che il mondo FLOSS
(inteso come lo e` oggi) era agli albori, e in questo contesto dire
"Perche` devo utilizzare qualcosa fatto da tizio quando lo posso fare da
me?" era una frase inusuale (l'uomo e` prima protagonista, poi
collaborativo). Inoltre, se si permetteva una situazione come quella
generata da KDE, si creava un grosso e pericoloso precedente, ovvero che
il FLOSS per essere competitivo necessitava di componenti closed (non
per nulla assieme a GNOME nacque il progetto Harmony). E` quindi normale
(se non fisiologico) che si sia creata una situazione del genere, anche
oggi sembra inusuale
Enrico

 manager (Gnome) e non solo fare una versione libera delle QT?
Dimenticavo: allora KDE veniva visto come la perfetta antitesi al mondo
OS e *nix, il primo motivo l'ho gia` spiegato, il secondo e` dovuto al
fatto che per essere sviluppato utilizza il C++ e non il "puro" C
Enrico

 fatti ogni volta che si aggiungono feature con ogni rilascio.
vero. peccato che tra i s.o. sia quello coi merge più veloci. Dipende
cosa si vuole.

 E' un argomento per la cui trattazione si rischiano, a mio parere:
C'e' un libro che, a mio parere, vale la pena leggersi sull'argomento:
Open Sources.
Ne esiste anche una versione italiana.
C:\>iao Angelo

 fatto che per essere sviluppato utilizza il C++ e non il "puro"
Perché, secondo te, è un male? Per me C++ è un gran linguaggio con concetti
interessanti ed ha poco senso lavorare in C ad oggetti con sporchi trucchi
quando vi è già un linguaggio che supporta l'OOP nativamente...

 nativamente...
Io ho visto dell'ironia nella risposta di Enrico... nota le virgolette
su "puro". ;-)
Secondo me riportava il "pensiero" di altri.
David
-- 
 . ''`.  Debian maintainer | 
http://snipurl.com/gofoxygo/
 : :'  :  Linuxer #334216  |  
http://www.hanskalabs.net/
 `. `'`    GPG: 1392B174   | 
http://www.debianizzati.org/
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174

 quando vi è già un linguaggio che supporta l'OOP nativamente...
Di senso ne ha molto nel momento in cui vuoi nascondere i dettagli
ed evitare di scrivere porcate... Indubbiamente e' un paradigma che
devi imporre tu, visto che il compilatore non ti aiuta...
La conseguenza e' la richiesta di un maggiore rigore da parte del
programmatore.
C:\>iao Angelo

 boh ... forse mi sfugge qualcosa.
Ti sfugge che è nato prima KDE, e che Gnome fu promosso da de Icaza sotto
auspicio di Stallman proprio perchè KDE usava le (allora non libere) QT. 

 de Icaza
Ricordiamo che de Icaza è l'autore della copia della copia di Java, nonché
di Beagle, il segugio grasso che vuole integrarsi con Gnome.
"anche nell'OSS esistono delle contraddizioni" cit.

 Non sono riuscito a coglierlo. Lo riproporresti?
E` nell'altro mio post in risposta a harlock
Enrico

 quando vi è già un linguaggio che supporta l'OOP nativamente...
Al di la dei gusti personali, personalmente non mi importa molto con
quale linguaggio venga scritto un applicativo. Sembra pero` la norma
snobbare in linux[1] tutto cio` che e` creato con linguaggi differenti,
poco importa se il prodotto risultante puo` essere sviluppato in minor
tempo ed avere un'efficienza simile (se non migliore)
Enrico
[1] ma non solo, anzi, sembra essere un dogma per tutti gli ambienti *nix

 De raadt sarebbe intelligente?
Beh, da questo punto di vista e` proprio cosi`
Enrico



Qualcosa evidentemente sbaglia. Pero' sono convinto che Linux - oggi - 
potrebbe essere un progetto ben piu' complesso di BSD, con piu' gente che 
lavora, con piu' cose che bollono in pentola, ci sono fork, e ci sono 
tanti altri casini.
Voglio ricordare che ci sono varianti di BSD dove gli sviluppatori attivi 
sono pochissimi (meno di cento), e dove da tempo si fa realmente poco.


 sono pochissimi (meno di cento), e dove da tempo si fa realmente poco.
netbsd?

 sono pochissimi (meno di cento), e dove da tempo si fa realmente poco.
Non conta mica la quantita' sai, conta la qualita'. Che me ne faccio di
10000
sviluppatori, di cui solo 100 sono in grado di mettere mano al kernel, e
gli altri
sono solamente buoni a creare distribuzioni e fare fork di qualsiasi
cosa pur di
dare vita ad un proprio progetto personale (che spesso rimane incompiuto)?
Non sarebbe piu' produttivo che ci fosse una convergenza tra questi
programmatori,
per creare finalmetne qualcosa di decente? Linux a quest'ora sarebbe
anni avanti rispetto
a Windows.
-- 
Posted via a free Usenet account from 
http://www.teranews.com

 fatti ogni volta che si aggiungono feature con ogni rilascio.
Infatti il codice del kernel di Linux e' il peggiore tra quello degli
unix liberi,
non il meno peggio.


 non il meno peggio.
Intendevo naturalmente che è il meno peggio considerando pro e contro di 
tutti gli unix liberi. Uno dei grandi pro è il supporto a un numero 
elevato di periferiche (molto più di un bsd, converrai).

 elevato di periferiche (molto più di un bsd, converrai).
Ohh. quello di sicuro.


 a Windows.
no, no, linux è "evolution" :D
-- 
NoWhereMan (e.v.)
-- 
http://www.nowhereland.it
-- 
http://flatpress.nowhereland.it

 no, no, linux è "evolution" :D
manca la parte finale... "not intelligent design" :O)



credo di si. Avevo trovato un sito con la lista delle persone iscritte al 
progetto (adesso dovrei cercare nuovamente quella pagina).


 a Windows.
difatti NetBSD e' notoriamente anni avanti rispetto a Windows......
dharma, lasciamo stare con queste cazzate e con questo parlare di un OS 
che nemmeno voi usate. O vuoi farmi credere che posti da una macchina 
windows virtuale, installata sul tuo openbsd?
Siamo seri.
Io non ce l'ho con *BSD, ma questi vostri, sono ragionamenti elitari 
senza molto senso pratico.... anche perche' - lo ripeto - *voi* BSD non 
lo usate.
Se invece tu mi dicessi cose molto piu' pratiche e sensate io sarei 
sicuramente d'accordo con te. 
Un esempio di ragionamento sensato: fare un cluster firewall con PFSYNC/
CARP e sicuramente meglio che usare iptables.


 non il meno peggio.
dharma, ma tu conosci il C, sei a conoscenza delle tecniche di 
programmazione del kernel, o stai completamente straparlando di cose 
delle quali non capisci nemmeno lontanamente un ca$$o?



Ada, io ti ho postato tempo fa delle cosette interessanti sul
kernel Linux. Commentando il codice.....
Già dimenticato ?



difatti io non ho risposto al dr. Pegasus
E' palese che tu sei a conoscenza.... ma lasciami dubitare di Dharma :)
Comunque: no, non mi ricordo bene. Se hai quella roba sottomano la puoi 
postare di nuovo.
p.s.:
1) non parliamo di microkernel, perche' in linea di massimo sono 
d'accordo con te. Piu' che altro per questioni di praticita': la completa 
esternalizzazione dei driver renderebbe la vita piu' facile a tutti
2) la questione dell'HAL della quale parlavi, si riferisce invece ad una 
tecnica, ma insomma e' una questione IMHO non importantissima.


 lo usate.
Ma sai una sega cosa uso io e non te. Io uso freebsd da quando probabilmente
tu nemmeno conoscevi come si accendeva un pc.


 delle quali non capisci nemmeno lontanamente un ca$$o?
Io semplicemente analizzo il codice dei vari kernel, e trovo quello di
linux, un casino totale. Non sono mica il solo a dirlo. Anche persone che
lavorano al kernel stesso lo dicono di tanto in tanto.


 Ma i server sono tutti unix e bsd.
mammasantissima: cosa ci fate con i server BSD?
Avete server di marca? Per quale precisa ragione avete installato un OS 
non supportato da nessun vendor? .... spero ci sia una ragione ben 
precisa, e non perche' ha il codice piu' bello.
Gli uptime di linux sono sufficientemente alti, software veritcalizzato 
ne esiste una marea.
Comunque, in alcuni casi ci sono ragioni ben precise per cui e' 
preferibile usare BSD, ma non mi parlare di cazzate, di codice bello e 
codice brutto.


 che lavorano al kernel stesso lo dicono di tanto in tanto.
mannaggia, eccone un altro che ha analizzato 5 milioni di righe di codice 
e ha capito tutto in un solo istante :)
Com'e' che Linus non se ne accorge e tu si?


 Com'e' che Linus non se ne accorge e tu si?
Oh, si che se ne accorge. Basta leggere alcuni suoi messaggi.


 ne esiste una marea.
Non mi piace come viene sviluppato.


 piu'.
Non è solo una questione strettamente numerica, è che gli sviluppatori 
in più sono venuti da "fuori", dalle aziende che adesso si scrivono i 
driver e partecipano allo sviluppo.
http://lwn.net/Articles/237196/

 lavorano al kernel stesso lo dicono di tanto in tanto.
"All software sucks", altrimenti non ci sarebbe stato motivo
di andare oltre 4.4BSD, l'ultimo vero BSD; era già perfetto :)

 lo usate.
Vedo che come tuo solito, non hai capito una cippa di come funzionano
le cose nel mondo BSD.
Il confronto Linux vs. NetBSD non può essere fatto, ed è inutile che lo
riproponi ogni volta, perchè l'obiettivo di NetBSD non è quello di Linux.
Linux, attualmente, è venduto e hype-ato come sistema operativo general
purpose, ossia come sistema operativo che può essere usato un pò per
tutto, sia come server che come desktop.
NetBSD non è nato con quello scopo. E' un sistema operativo di nicchia, non
ha lo scopo di lanciarsi sul desktop in ogni famiglia domani mattina, non è
nato per quello. Non sentirai mai dire "Domani batteremo Windows", ad
un developer NetBSD, non è quello il suo scopo.
Il suo scopo è quello di fornire un core completo velocemente portabile su
piattaforme non standard. Se io dovessi portare un sistema operativo
completo su un ricevitore satellitare gold box, partirei dal codice di 
NetBSD, non
dal codice di Linux (solito discorso: HAL based). E prima che tu dica che 
però
Linux supporta più piattaforme di NetBSD, io ti rispondo che la cosa non
ha il benchè minimo significato, perchè nel caso di Linux, quando si dice
che vengono supportate X piattaforme, si intende che ci sono X versioni del
solo kernel, mentre nel caso di NetBSD, quando si dice che vengono
supportate X piattaforme, si intende che ci sono X versioni ****di tutto
il core****, ossia di tutto un sistema operativo completo.
Non solo: NetBSD supporta comunque caratteristiche che Linux non ha, per
esempio la virtualizzazione del funzionamento del bus, cosa che fa veramente
comodo a qualsiasi ingegnere elettronico (me compreso), perchè significa che
io posso usare un driver NetBSD per una scheda Ethernet PCI non solo sul
bus PCI di una scheda madre x86, ma anche sul bus PCI di qualche MacPPC,
semplicemente dopo una normale ricompilazione.
Possiamo confrontare Linux con OpenBSD? Nemmeno.
OpenBSD è un altro sistema operativo di nicchia. Non è nato come sistema
operativo per il desktop: è nato come sistema operativo per banche, centri
di ricerca, amministrazioni pubbliche. Non serve a farci girare KDE, serve
a fare girare in un ambiente sicuro dei programmi che trattano cose come
sicurezza nazionale oppure milioni di dollari.
Quindi, non ha senso il confronto che fai.
Con chi si dovrebbe confrontare Linux ? Semplice: con FreeBSD e con MacOSX.
Ed i fatti sono testardi: finchè FreeBSD era un sistema server specializzato 
per
essere stabile e veloce, è chiaro che non c'è stata partita. Adesso che, 
****in
pochi mesi****, il team PC-BSD tira fuori una bella distribuzione desktop
basata su core FreeBSD, elegante, semplice, veloce e facile da usare, PC-BSD 
inizia
a diffondersi ed ad erodere quote a Linux. Certo, Linux è molto avanti 
perchè
è un progetto più antico e sostenuto da un hype pazzesco, ma io mi 
preoccuperei
tenuto conto di quello che in pochi mesi sono stati in grado di creare con 
PC-BSD,
roba che Mandrivia ci ha messo 10 anni per arrivare ad avere lo stesso 
livello
di funzionalità.....
Chi rimane: MacOSX. E qui sono mazzate per Linux, perchè mi pare che Linux 
sia,
sul desktop, meno diffuso di MacOSX. Questa è la realtà.
Il grosso del numero, per i BSD, lo fa naturalmente MacOSX.
Questa è la realtà.

 Non è solo una questione strettamente numerica
Però è bella consistente :)
http://www.kroah.com/log/diary/2007_06_25.html


http://groups.google.it/group/it.comp.os.dibattiti/browse_frm/thread/66b28bd9b50c9f5a/5fe08de91a166699?lnk=st&q=linux+fatti+non+pugnette&rnum=3&hl=it#5fe08de91a166699

 
http://groups.google.it/group/it.comp.os.dibattiti/browse_frm/thread/66b28bd9b50c9f5a/5fe08de91a166699?lnk=st&q=linux+fatti+non+pugnette&rnum=3&hl=it#5fe08de91a166699
Quella è una famiglia di driver IDE non più sviluppata, ci vanno solo
i bug fix che correggono un bug reale.
Al suo posto da qualche anno c'è libata scritto da 0 come si deve
che supporta SATA e PATA con error handling e locking migliori e
un sacco di altre cose.

 E prima che tu dica che  però Linux supporta più piattaforme di NetBSD,
Non e' assolutamente vero.


 progetto (adesso dovrei cercare nuovamente quella pagina).
netbsd è quasi morto, se non è già morto.
Ha un anno, ma era significativa:
http://kerneltrap.org/node/7061

 dare vita ad un proprio progetto personale (che spesso rimane incompiuto)?
non basta un kernel a fare un sistema operativo.

 
http://kerneltrap.org/node/7061
Si sono riorganizzati, progetti come NetBSD praticamente
non muoiono mai.  Possono rallentare come il metabolismo di
un orso che va in letargo ma non muoino.
C'è ancora gente che sottomette patch per BSD 2.11 su
piattaforma VAX :)

 sicurezza nazionale oppure milioni di dollari.
infatti wall street usa openbsd.....
Quando decidi di uscire dalla tua cameretta e vedere come gira il mondo?

 non muoiono mai.
sarà, certo che si errori ne hanno fatti. il fork di openbsd è stato un
duro colpo, per esempio

 non il meno peggio.
io su questo avrei da ridire. non è che quello di openbsd sia questa
bellezza, anzi.
i bsd si portano dietro questi miti, che però, insomma, sono così vecchi
che forse non sono più attuali.

 Non mi piace come viene sviluppato.
cos'e' che non ti piace? Non ti piace Oracle?
Ma lo vedi che non sai nemmeno di cosa stai parlando?


 realtà.
Non ci siamo. Anzi, vedo che ci risiamo... e dire che ne avevamo gia' 
parlato.
Come fa un microkernel ad essere considerato BSD che e' un monolitico? 
Non era gia' stato chiarito che MacOSX e' un kernel Hurd con intorno una 
serie di tool BSD?


 serie di tool BSD?
Hai dimenticato i sette nani
-- 
In a minute there is time for decisions and revisions which a minute
will reverse
T.S. Eliot

 linux dove hanno portato *solo* il kernel.
e diciamo anche un'altra cosa:
Linux nel 99.9% dei casi si usa su x86, x86_64, sparc, powerpc, mips, arm 
e alpha.
Windows oggi gira solo su x86 e in qualche caso x86_64.
MacOSX ormai gira solo su x86
Il resto degli unix girano tutti su un solo tipo di hardware (tranne hp-
ux che va su IA64 e PA-RISC).
Il resto e' roba che serve solo a fare "scumazza" (Filippo mi capisce) e 
discussioni piu' o meno inutili.


 Hai dimenticato i sette nani
sarcasmo a parte, che non capisco nemmeno, MacOSX e' solo parzialmente un 
kernel BSD, in quanto consiste maggiormente del kernel XNU.
Mach
The core of the XNU kernel, Mach, provides kernel threads, processes, pre-
emptive multitasking, message-passing (used in inter-process 
communication), protected memory, virtual memory management, very soft 
real-time support, kernel debugging support, and console I/O. The Mach 
component also allows the OS to host binaries for multiple distinct CPU 
architectures within a single file (such as x86 and PowerPC) due to its 
use of the Mach-O binary format.
BSD
The BSD portion of the kernel provides the POSIX API (BSD system calls), 
the Unix process model atop Mach tasks, basic security policies, user and 
group ids, permissions, the network stack, the virtual file system code 
(including a filesystem independent journalling layer), cryptographic 
framework, System V IPC, and some of the locking primitives. The BSD code 
present in XNU came from the FreeBSD kernel, although much of it has been 
significantly modified, and significant on-going code sharing occurs 
between Apple and the FreeBSD Project



No. Non è vero.
E non è che ripetendo sta cretinata questa diventa più vera.....
Il nucleo di MacOSX è il kernel XNU: non c'è traccia di Hurd o roba
GPL alla Stallman.
O meglio, per essere più precisi: è un kernel che contiene sia il codice 
XNU,
sia il codice BSD. Ed è lì che sta il bello.
In pratica, non sta scritto proprio da nessuna parte che un BSD debba essere
monolitico. I BSD non sono dei kernel su cui tu puoi mettere quello che te
pare (alla Linux per intenderci): sono dei sistemi operativi ***completi***, 
il
cui ***core*** è costituito da un certo numero di componenti ben
definiti e determinati, e che definiscono in modo rigoroso le specifiche sia
dell'interazione processi/kernel, sia dell'userland.
Nel kernel di MacOSX, il livello superiore contiene il codice BSD, e 
gestisce
gli utenti, i permessi, lo stack di rete, il virtual file system, tutto in 
modo
compatibile con le specifiche BSD. Il livello inferiore, invece, è il codice 
XNU,
che si occupa di generare interrupts, di gestire la memoria, di gestire la
memoria virtuale e di accedere all'hardware.
La soluzione è simile a quella prevista per Windows NT: le applicazioni 
parlano
con il nucleo BSD ad alto livello (server di ambiente), e poi questo 
provvede
ad inviare le chiamate sul nucleo microkernel Mach. Ed infatti, leggendo, 
sto
trovando proprio scritto "sottosistema BSD".
Cioè, ritornano i beneamati sottosistemi che, come già ti feci notare una 
volta,
permettono di fornire alle applicazioni-utente API compatibili con un certo
ambiente operativo, anche se sotto è presente solo un microkernel (nel
caso di NT, perchè il sottosistema contiene un processo che emula un
kernel.... non so nel caso di MacOSX come funzioni...).
Anzi, guarda, o anche fatto una veloce ricerca su wikipedia:
http://it.wikipedia.org/wiki/Apple_Darwin
Come vedi, è progettato per essere pienamente compatibile con il codice BSD,
malgrado sia un quasi-microkernel (non è un microkernel puro...).
/cite/
Infatti, implementa identiche le BSD system calls, la gestione dei processi,
i livelli base di sicurezza e le relative policy, l'user id, la gestione dei 
permessi,
la gestione della rete, il Virtual file system (incluso la strato di 
journaling),
la crittografia, le UNIX System V IPC
/cite/

 
Il sarcasmo era dovuto al fatto che avevi scritto Hurd invece di Mach.
In ogni caso XNU è la totalità del kernel, che è Mach+BSD+IOKit (la
parte per i driver)


 /cite/
fili', non mi fare perdere. 


 non basta un kernel a fare un sistema operativo.
Ma nemmeno 10000 programmatori che non fanno altro che forkare,
dove ognuno tira l'acqua al suo mulino.


 Ma lo vedi che non sai nemmeno di cosa stai parlando?
certo che quando ti ci metti fai veramente bene la parte
del coglione.



Non avevo ancora letto quello che hai scritto.
Ma la questione, Ada, sempre la stessa è: Mac-OSX è un BSD.
Quindi è perfettamente inutile continuare a proporre scontri Linux vs BSD,
perchè non esiste BSD, esistono tanti sistemi operativi BSD completamente
diversi come obiettivi già a livello kernel.
Lo scontro, se tu volessi essere onesto, sarebbe tra Linux e MacOSX.

 Lo scontro, se tu volessi essere onesto, sarebbe tra Linux e MacOSX.
Mettiamola cosi': che scrive non ha un Mac e chi legge nemmeno.
tu compreresti un Mac? Ne hai uno?
Dubito che ne compresti uno.
Quindi per chi fai il tifo?


 certo che quando ti ci metti fai veramente bene la parte del coglione.
non si capisce cosa hai risposto.
Non ti piace come viene sviluppato cosa?
Il software per linux? Il kernel?
aspetto ancora un esempio di cattivo codice che tu avresti incontrato 
guardando i sorgenti....


 serie di tool BSD?
non è un kernel hurd. non è vero che ogni driver viene eseguito in un
processo indipendente dagli altri.

 between Apple and the FreeBSD Project
eccolo qua: il microkernel fa girare un blocco monolitico.
A 'sto punto è meglio il monolitico secco.

 dove ognuno tira l'acqua al suo mulino.
ma non è vero che ci sia un fork selvaggio.
a voler essere onesti, ci sono stati più fork per il kernel bsd che
linux... Non esitono freelinux, netlinux, openlinux e dragonflylinux con
kernel tutti simili ma diversi.

 Quindi per chi fai il tifo?
Per il Milan.
Non è questione di fare il tifo Ada. E' questione strettamente tecnica: qui 
non
stiamo a fare il tifo per Linux o Windows o MacOSX o per uno dei quattro
BSD rimanenti. Qui si parla di questioni tecniche, del tifo a me non può
fregare di meno.

 non si capisce cosa hai risposto.
Se quoto una frase di questo tipo:
"Gli uptime di linux sono sufficientemente alti, software veritcalizzato
ne esiste una marea."
E scrivo:
Non mi piace come viene sviluppato,
Secondo te , di cosa staro' parlando? Del tema di mio cugino all'esame di
maturita'?


 kernel tutti simili ma diversi.
In compenso esistono 450000 distribuzioni.


 BSD rimanenti. 
Errato. La maggior parte delle persone che sono pro-linux, qui dentro e
anche fuori da questo NG sono tifosi.


 Quando decidi di uscire dalla tua cameretta e vedere come gira il mondo?
Giusto.
Sono uscito dalla mia cameretta, e mi hanno informato che, ad esempio, la
DARPA ha finanziato OpenBSD fino a qualche tempo fa (ossia, finchè
De Raadt non ha fatto alcune dichiarazioni pacifiste riguardo alla guerra
in Iraq), e che è usato anche dalla NASA e da altri 2 o 3 centri
governativi americani. Robetta.

 di maturita'?
Ora ho capito! Ti riferivi a come viene sviluppato il software 
verticalizzato per Linux. :P 


 anche fuori da questo NG sono tifosi.
certo. Tu non sei tifoso e te piace bsd a ragion veduta.
E il fatto che sia di moda non c'entra niente.
Credetegli.




e' stato un  lapsus: gnu hurd usa gnu mach, e macosx usa xnu mach.
ho fatto confusione e ho scritto hurd (che non c'entrava nulla)


 certo. Tu non sei tifoso e te piace bsd a ragion veduta.
Esatto.


 kernel tutti simili ma diversi.
Assolutamente vero.
-- 
BArrYZ

 kernel tutti simili ma diversi.
Mio Dio, Ottavio.....
da un lato ci sono 4 sistemi operativi completi con kernel totalmente
diversi, dall'altro ci sono 30 distribuzioni con lo stesso kernel, ma
sempre leggermente differente, sempre leggermente differentemente
patchato, sempre leggermente incompatibile a livello ABI con i
drivers dell'altra distribuzione, ecc. ecc. ecc......

 dell'altra distribuzione, ecc. ecc. ecc......
Ca$$o a te, ai tuoi ABI, HAL, CRIC, CRAC e tutte le tue storie assurde :D
1) nessuno ti vieta di usare vanilla in qualsiasi distro. Ti giuro che 
funziona :D ...certo perderei lo splash screen di gentoo e altre cagate 
di questo genere, ma in portage c'e' tanto di pacchetto: sys-kernel/
vanilla-sources
2) Fili', ti sei mangiato le cozze allocinoge.
Un driver puo' essere usato in qualsiasi distribuzione, e con qualsiasi 
kernel della stessa serie (2.6.xx). E' vero che alcuni driver per gentoo 
hanno delle patch, ma non c'entra nulla.
Io, con il kernel patchato da gentoo posso anche usare il driver ATI 
preso dal sito della ATI, al posto di quello patchato da gentoo. Funziona 
alla perfezione. Non lo faccio per non perdere il vantaggio di poter 
utilizzare il sistema di aggiornamento dei pacchetti della mi 
distribuzione.
Infine: sai - per esempio - a cosa serve la patch al driver ATI?
risposta: serve ad aggiungere alcune utilita' relativa alla distribuzione 
gentoo. Ad esempio alcuni file relativi alle impostazioni di ambiente 
specifici per gentoo, o uno init script:
/etc/env.d/03ati-colon-sep
/etc/env.d/04ati-dri-path-amd64
/etc/env.d/04ati-dri-path-x86
/etc/init.d/atieventsd
/etc/acpi/ati-powermode.sh
/etc/acpi/events
Il codice del driver non viene toccato neanche minimamente.


 vanilla-sources
ma te non sarai per caso un fanatico di gentoo? Perche' in questo caso,
evito di discutere con te.


 evito di discutere con te.
La uso ma non sono un fanatico.
Addirittura alcune cose di gentoo a volte mi piacciono, altre volte mi 
sembrano difetti :)
Esempio pratico:
1) viene aggiornata frequentemente!
2) viene aggiornata *troppo* frequentemente!
A volte esagerano, fanno dei "minor changes", aggiungono un USE flag e ti 
tocca reinstallare cose come kdelibs, qt, mozilla. L'ho fatto presente e 
mi hanno detto che non possono fermare il treno in corsa.
E' completamente assurdo che non possono aspettare un major update per 
risolvere questi stupidi problemi di flag.
Ultimamente ci sono aggiornamenti disponibili 2 volte al giorno!!!
Se vuoi possiamo parlarne... ma e' un po' un'altra questione.
Ad ogni modo: gentoo va bene solo ed esclusivamente sul mio PC, ma non 
credo che la userei per nessun altro scopo.


 hanno delle patch, ma non c'entra nulla.
Davvero ? Ma è bellissimo.
E dimmi una cosa: i flag di compilazione del kernel sono standardizzati
da qualche documento (per la serie 2.6.xx) ?
I simboli del kernel disponibili ?

 I simboli del kernel disponibili ?
Fili' ... non mi sembri piu' tu.
"man nm" ..... "nm mitilo.ko" "nm tellina.ko" "nm cozza.ko"
Provare per credere!


 serie di tool BSD?
Non HURD. Mach. Per inciso MacOS X è un microkernel come struttura, ma
poi per ragioni di performance gira tutto in kernel space.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 A 'sto punto č meglio il monolitico secco.
Con tutte le motivazioni che hai addotto, ti credo di sicuro.
- Hint: perfino Linux si distacca dall'approccio monolitico classico e
c'č appunto una convergenza al centro fra monolitico e microkernel dove
si cercano di bilanciare  vantaggi e svantaggi dei diversi approcci.


 microkernel. Quello e' pertanto un kernel linux.
Come ti sta cercando di fare capire non esiste il concetto di Kernel
BSD. Se espandi la sigla BSD dovrebbe scattare un campanello d'allarme.
BSD sta per Berkeley Software Distribution.
BSD è stato un sistema operativo ben preciso (come a suo tempo lo è
stato UNIX). Ora è una famiglia di sistemi operativi che discendono
liberamente da esso.
Il fatto che MacOS X sia o meno parte di questa famiglia è una questione
abbastanza leziosa. Siccome non esiste una definizione completamente
formale di questo ed è più che altro una questione filosofica, puoi o
meno ficcarci dentro MacOS X.
Indubbiamente ci sono parentele strettissime con gli altri BSD. Non a
livello di kernel, ma appena sopra. Ancora prima di MacOS X, NeXT era
legato a BSD (e in periodo in cui c'era ancora differenza fra BSD e
SysV).
Poi ribadisco, questa è una questione IMHO poco rilevante.
Tu piuttosto sapevi che esistono anche versioni di Linux a
*microkernel*?
Per esempio MkLinux (ora defunto) era un'implementazione di Linux sopra
Mach 3. Io lo ho pure usato, fra l'altro. Penso che sia stato il primo
Linux che ho usato, in effetti. Doveva essere tipo il 97 o il 98. 


 poi per ragioni di performance gira tutto in kernel space.
Ma.. oltre allo stack di rete e alle syscall BSD, pure i driver
girano in kernel space? Perché già senza i driver ho i miei dubbi,
ma fosse così non vedo proprio come si possa chiamarlo microkernel.


Davvero ?
Ma è fantastico. Mi stupisci ancora di più.
Tu pensa che su Nanodesktop, se io uso un driver ndUsbDriver.Prx
su una versione del Nano compilata con l'opzione -fshort-double e
su una versione del Nano che è stata compilata senza tale opzione,
il driver si incazza **di brutto**.
Ti faccio un esempio adatto alle tue capacità di comprensione. Abbiamo 
questa
funzione
void MsgToAdamo (double x)
{
    printf ("Adamo non capisce \n");
    printf ("Coefficiente preparazione %f \n", (float)(x) );
}
in un modulo del kernel Linux di una generica distribuzione che per 
convenzione
chiameremo LinuxDistrA.
Bene, i tizi che fanno il kernel su quella distro decidono di compilare il 
kernel
(ed il modulo...), senza opzione -fshort-double.
Ciò significa che al parametro x verranno assegnati 64 (o 80 dipende dalla
piattaforma) bits di sizeof. Supponiamo per semplicità che siano 64 (ossia
2 longword a 32 bit).
Quando il kernel al livello superiore intende richiamare la funzione 
MsgToAdamo,
succede questo:
LIVELLO KERNEL CORE
                                Push in stack 32 bit (Banco 0)
                                Push in stack 32 bit (Banco 1)
--------------------------------------------------------------------------
CODICE BINARIO DEL DRIVER
                                Pop from stack 32 bit (Banco 1)
                                Pop from stack 32 bit (Banco 0)
                                        -----------> Esegui la funzione
Bene, finchè il modulo è stato compilato insieme a tutto il kernel la cosa 
funziona bene.
Vediamo ora se è garantita l'interoperabilità.
Su un'altra distribuzione, che per convenzione chiameremo LinuxDistr1, il
mantainer del kernel decide di compilare i loro kernel con 
l'opzione -fshort-double.
In questo modo, i double saranno trattati come i float a 32 bit. Verrà persa
precisione, ma si guadagnerà velocità (su certe piattaforme è un trucco
furbissimo per velocizzare il sistema, vedi MIPS/PSP ad esempio....).
Bene, ora abbiamo il nuovo kernel LinuxDistr1, compilato come dice il
mantainer, e dobbiamo usare il driver. Poichè non vogliamo ricompilare il
driver (magari la società non vuole darci i sorgenti, ma ci dà solo il 
modulo
compilato per la distribuzione LinuxDistr0), non sappiamo come fare.
Idea! Chiediamo ad un esperto: ADAMO.
E lui ci dice, dal suo posto di lavoro alla Sun, che nooooooooon c'è
prooooobleeeeeema. Tranquiiiiiiiiiiiiiiiiilli.
Tanto tutti i moduli progettati per i kernel 2.6.x sono intercambiabili, e 
quindi
è sufficiente il modulo binario compilato per LinuxDistr0.
Ok, tutti contenti facciamo un bel cp su un floppy per copiare sto modulo,
e poi un bel insmod sulla nostra LinuxDistr1. La nuova situazione è
la seguente:
LIVELLO KERNEL CORE (viene da LinuxDistr1)
                                Push in stack 32 bit (Banco 0)
--------------------------------------------------------------------------
CODICE BINARIO DEL DRIVER (compilato da LinuxDistr0 e copiato...)
                                Pop from stack 32 bit (Banco 1)
                                Pop from stack 32 bit (Banco 0)
                                        -----------> Esegui la funzione
Notate che il codice binario del driver resta lo stesso, solo che 
disgraziatamente,
così il kernel della nuova distribuzione considera i float a 32 bit e manda 
UNA
sola parola a 32 bit in stack, mentre il driver considera i float a 64 bit e 
cerca
di prenderne DUE di parole dallo stack.
Il chè forse mi dice, ma come sapete io sono un ragazzetto senza esperienza,
che esiste una leggerissima possibilità che questo, in kernel mode, possa
causare qualche piccolissimo problema tecnico......
Direte voi: elucubrazioni mentali. Giusto. Ma consideriamo un altro caso.
Abbiamo una struct nel core del kernel che si chiama così:
struct StrutturaVattelapesca
{
      int a0, a1, a2, a3;
}
Che succede se in qualche patch, qualcuno cambia la struct in modo
che diventi:
struct StrutturaVattelapesca
{
      int a0, b, a1, a2, a3;
}
In questo caso è vero che l'indirizzo relativo di a1, a2, a3 cambierebbe e 
quindi
tutti i vecchi moduli dovrebbero essere ricompilati per continuare a 
funzionare
con la versione patchata del kernel ?
Certo, se i sizeof delle variabili, se i prototipi delle funzioni esportate 
dal kernel,
e se le strutture dati del kernel fossero definite in un documento 
ufficiale,
allora saremmo in presenza di una ABI stabile ed il problema non si
porrebbe.
E' così sotto Linux ? Oppure l'ABI stabile non è considerata sensata dai 
kernel
developers ?
 

Precisazione (prima che arrivino Paolitto ed il Campana)
ho fatto l'esempio della chiamata stack based. Se
siamo su una piattaforma a chiamate interrupt/registers
based, fate voi il ragionamento equivalente

 incazza **di brutto**.
Fili' tu sei malato.
I varianti di flag utilizzati per la compilazione sono 2 o 3.
Le tue cazzate sono molto teorica.


 governativi americani. Robetta.
quanti sono i cluster pagati dal DoD su cui gira openbsd? 0.

 si cercano di bilanciare  vantaggi e svantaggi dei diversi approcci.
hurd è una idea molto carina, ma purtroppo si è dimostato molto
difficile da debuggare. alla faccia di chi sosteneva il contrario, tra
cui RMS.

 (permessi, utenti) che rende un sistema operativo un BSD.
allora linux è un bsd. A che il layer posix di windows lo rende un bsd.

 ficcarci le mani dentro, usi le API tipiche di un BSD.
la definizione è sbagliata. tanti altri s.o. a questo punto sarebbero bsd.


guardala così: come mai l'aggiornamento 10.4.10 impalla la airport e hai
kernel panic? se i driver fossero indipendenti saresti senza rete, non
senza sistema operativo.

 
tu palravi del kernel ed io mi riferivo al kernel.


Come no.
Perchč non glielo vai a dire a questi signori ?
http://sebastian-bergmann.de/archives/473-Trouble-with-the-NVIDIA-Linux-Driver.html
http://ipw2100.sourceforge.net/
Sě, nel secondo c'č proprio scritto:
a.. Compatibility update for 2.6.19 above kernel workqueue API change
a.. Fix external module compiling symbols not found warning

 ma fosse così non vedo proprio come si possa chiamarlo microkernel.
Per *come* è fatto. Per la separazione dei componenti e per il fatto che
la comunicazione avvenga appunto principalmente tramite messaggi.
In linea teorica si dovrebbe riuscire a fare diventare tutto un
microkernel vero con una fatica relativamente piccola.
Comunque non a caso lo chiamano microkernel ibrido. 


 drivers dell'altra distribuzione, ecc. ecc. ecc......
che detta da uno che non sa la differenza tra api e abi...

 evito di discutere con te.
che cosa bella e rara che è l'apertura mentale.....

 I simboli del kernel disponibili ?
sono di fatto standardizzati dal 2.6.x.0

 il driver si incazza **di brutto**.
eh beh, se non trova i sorgenti! :-P
dai, scusa, torno serio.
Il tuo esempio è sbagliato per un motivo molto semplice: chi compila il
kernel compila anche la libc di conseguenza. Non accade mai che compili
la libc in un modo e il kernel in un altro, perché è noto che NON
funziona. E' come prendere un programma in C e pretendere di linkarlo ad
una libria C++...
bello scoprire l'acqua calda...
Tra parentesi, quando scoprirai che -fshort-double non è usato nei
kernel perché è prassi ragionare direttamente sulla lunghezza dei tipi
di dato e definire dei typedef adeguati?

 based, fate voi il ragionamento equivalente
non cambia, rimane una banalità.

 Comunque non a caso lo chiamano microkernel ibrido. 
il suo vero nome è monolitico vestito da micro.
fate un giro sul forum di apple e vedrete quando kernel panic ci sono
che non dovrebbero esserci se fosse micro.

 microkernel vero con una fatica relativamente piccola.
In linea teorica, e in pratica? :)

 cui RMS.
Al di la di tutto (ti faccio presente che ci sono fior di microkernel
stabilissimi in giro) immagino sia una questione di mancanza di risorse
e di interesse. O forse di errori di design, ma questo non posso dirtlo,
non avendolo analizzato.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 che non dovrebbero esserci se fosse micro.
Boh, io i kernel panic devo appunto andare a cercarli nei forum che dal
vivo non li incontro, ma a parte questo dal fatto che i driver siano in
kernel space discende anche che ci possa essere un kernel panic dovuto
ad essi.


 la definizione è sbagliata. tanti altri s.o. a questo punto sarebbero bsd.
Ma se non esiste neppure la definizione *formale* di 'BSD'... io quello
che posso dirti è che MacOS X condivide buona parte dell'user space di
freebsd.
Per cui se scrivi un programma in user-space e tratti OS X come fosse
freebsd ci imbrocchi. 
Poi il resto lo lascio a te. Mi pare che tu trovi molto divertente
cercare di dare le etichette. A me complessivamente interessa poco. 
Dopo di che spiegami in base a cosa trovi corretto chiamare FreeBSD,
NetBSD, OpenBSD BSD? In base al fatto che contengono codice di BSD 4.4?
Ammesso che sia rimasto qualcosa di quello in FreeBSD, probabilmente è
passato anche ad OS X. In base al fatto che finiscono per BSD? <g>


 cui RMS.
curiosità: com'è l'IPC tra server/processi su HURD?
-- 
NoWhereMan (e.v.)
-- 
http://www.nowhereland.it
-- 
http://flatpress.nowhereland.it

 allora linux è un bsd. A che il layer posix di windows lo rende un bsd.
:D mi pareva che però il discorso riguardasse i tool che rendono
'collaterali' al kernel che rendono un SO tale; allora in questo senso
(forse, se ricordo bene) un BSD è un BSD a prescindere dall'implementazione
del kernel... 
però potrei dire una cagata.
per le syscall, invece, se è POSIX son quelle, c'è poco da fare :D pegasus,
non ti lanciare.
Ottavio, però il tuo ragionamento ha una falla, linux non è POSIX al 100%
(per tipo, un 1%, vero? :D) quindi non è un BSD, eh. così non vale.
LOL
infine esattamente cosa distingue le ACL di un *BSD da quelle di un altro
unix o unix-like ?


 Linux che ho usato, in effetti. Doveva essere tipo il 97 o il 98.
Lo avevo letto e mi interessava! Come mai è defunto?


 non avendolo analizzato.
purtorppo ti sbagli, c'è pure la dimostrazione matematica che non può
funzionare. N code che vanno ad 1/n di velicità sono meno performanti di
una unica coda a velocità piena.
Triste ma vero.

 curiosità: com'è l'IPC tra server/processi su HURD?
prende ma mac la comunicazione con le porte, e poi rimappano le ipc unix
tradizionali su di esse.

 (per tipo, un 1%, vero? :D) quindi non è un BSD, eh. così non vale.
{free,open,net,dragonfly}bsd sono 100% posix? Afaik no (e pure secondo
wikipedia). E siccome nessuno implementa tutto allora nulla è uno unix.
http://en.wikipedia.org/wiki/POSIX
Altro esmepio per scardinare la biezione BSD<->POSIX: neutrino, il
microkernel di qnx è posix compliant. Ma è fuori discussione che non è
un BSD. Anche hurd nel suo molto piccolo è (leggi: vorrebbe essere se ci
fosse gente che lo sviluppa) posix compliant, ma non è un bsd.
Un bsd è un kernel fatto in una cera maniera. e basta.

 ad essi.
curiosità: hai aggiornato al 10.4.10?

 passato anche ad OS X. In base al fatto che finiscono per BSD? <g>
no, molto meno. Direi che mach e iokit non sono nemmeno comparabili con bsd.
Insomma, apple non dice che è macosx è un bsd. Dice che ha preso la
gestione di utenti, vm, processi e networking da bsd. Sono due
affermazioni diverse.
PS: il punto no è dare etichette. Il punto è avere delle definizione
abbastanza robuste da poter discutere essendo sicuri che tutti capiscano
univocamente i concetti.

 a.. Fix external module compiling symbols not found warning
Filippo, tu non sei un informatico, ma un pollo, per di piu' un po' 
drogato.
Mi stai portando l'esempio di 2 driver che contengono delle parti in 
formato binario e che in Linux rappresentano una vera eccezione.
Il primo (nvidia) e' binario, il secondo contiene invece un firmware che 
e' binario.
Essendo Linux stato concepito per usare driver opensource, sara' cura di 
chi fornisce driver in formato binario smazzarsi di volta in volta questo 
tipo di problemi.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 *microkernel*?
Non e' questo il punto. Il punto e' che il kernel MacOSX e' Mach proprio 
nella parte in cui e' microkernel. Ovvero, non e' il kernel di un BSD 
modificato a microkernel, ma appunto, qualcosa di diverso che era gia' 
microkernel in partenza: un kernel XNU Mach.


 che cosa bella e rara che è l'apertura mentale.....
La smettesse di pontificare ca$$ate sarebbe meglio per lui.
Fra le altre cose gli sfugge un piccolissimo particolare:
http://www.gentoo.org/doc/it/gentoo-freebsd.xml
Non gli piace proprio l'unica distribuzione Linux che puo' addirittura 
fungere anche da freebsd, addirittura aggiornato all'ultima release di 
freebsd:
ll /usr/portage/profiles/default-bsd/fbsd/
drwxr-xr-x 3 root root  296 Dec 13  2006 6.1
drwxr-xr-x 4 root root  240 Mar  1 17:06 6.2
....


 Esatto.
pero' non ti piace l'unica distro Linux che puo' essere trasformata in 
freebd 6.2 .... sempre a ragion veduta. Giusto?


 tipo di problemi.
IL CAZZO.
Aho, sistemucolo da quattro euro, io mi rivolgo ad Ottavio dicendo "sempre
leggermente differente e leggermente incompatibili a livello di ABI"
(ABI = Application ******Binary****** Interface), ed arrivi tu bello
contento e soddisfatto a dire
a) prima che non è vero, i drivers sono intercambiabili;
b) adesso si scopre che è vero, ed allora mi dici che però si può 
ricompilare
da sorgenti.
E che cazzo c'entra: si è sempre detto che devi ricompilarli i drivers 
proprio
perchè l'ABI stabile non c'è (non a caso i BSD questo problema non ce
l'hanno, MacOSX i drivers closed ti accetta senza problema alcuno).
Ma ci sei o ci fai ?


Ah si!
Adamo, ma tu mi sconvolgi !!!!!!!!!!!!!!!!!
Urca !!!!!!!!!!!!!!!
Vuoi dire che con Gentoo:
a) non esiste più la directory /proc, ma esiste l'utility standard per la
configurazione dell'hardware prevista per i BSD;
b) i nomi delle periferiche seguono le convenzioni BSD
c) è possibile avere la crittografia su tutte le pagine della memoria del
processo salvo quella richiesta di volta in volta dal programma
(OpenBSD), in modo da impedire il memory dump
d) è possibile avere una ABI standard
e) è possibile fare partire il sistema con rc.d
f) E' possibile avere le syscalls BSD e non le syscalls Linux ?
Il modello di chiamata syscalls cambia ?
g) Si può usare il file system di FreeBSD ?
FANTASTICO.
Ora mostrami come si fa.....

 preso e spostato.
Sono perchč hanno codice di qualitą molto migliore.
Per il resto, come ha sottolineato ngw in un famoso post, sono
molto diversi. Per esempio, uno supporta SMP, mentre l'altro no.
Uno critta e randomizza tutto ciņ che puņ crittare e randomizzare,
gli altri 3 assolutamente no.

 
http://www.gentoo.org/doc/it/gentoo-freebsd.xml
beh, prima sarebbe venuta 
http://www.debian.org/ports/kfreebsd-gnu/
 è da
un bel po' che gira, anche se in pochi se la filano. forse i fan di
gentoo più smanettoni apprezzeranno di più

 a.. Fix external module compiling symbols not found warning
e questo di soltio si riconduce a errore triviale nei sorgenti

 Ora mostrami come si fa.....
http://www.gentoo.org/doc/it/gentoo-freebsd.xml


 in freebd 6.2 .... sempre a ragion veduta. Giusto?
No, non è l'unica:
http://www.debian.org/ports/netbsd/
http://www.debian.org/ports/kfreebsd-gnu/
(da fedele maintainer Debian, porto avanti la mia bandiera :-P)
Saluti,
David
-- 
 . ''`.  Debian maintainer | 
http://snipurl.com/gofoxygo/
 : :'  :  Linuxer #334216  |  
http://www.hanskalabs.net/
 `. `'`    GPG: 1392B174   | 
http://www.debianizzati.org/
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174

 MacOSX i drivers closed ti accetta senza problema alcuno).
beh beh, io avrei da ridire, tra audio, usb firewire e airport hanno
fatto un casino.....
http://www.macfixit.com/article.php?story=20070625093827106

 allora linux è un bsd. A che il layer posix di windows lo rende un bsd.
Fesseria pazzesca per alcune ragioni:
a) le syscalls BSD e le syscalls Linux ***SONO DIVERSE***. Non
confondere compatibilità Posix con syscalls dell'OS.
Sia Linux che i BSD estendono le syscalls Posix con altre loro syscalls
che sono totalmente differenti. Tantovero che FreeBSD ha un layer che
traduce le syscalls Linux in syscalls BSD. E le syscalls BSD sono 
leggermente
più lente, ma molto più flessibili delle syscalls Linux. Cambia innanzitutto 
il
modello di chiamate (register based per Linux, stack based per i BSD),
poi esiste una tecnica particolare che copre la differenza di parametri tra
una release e l'altra del kernel BSD aiutando a mantenere stabile l'ABI.
In alcuni casi cambiano anche i numeri delle chiamate: qui c'è un
documento che spiega le differenze:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/x86-portable-code.html
Quindi, non puoi scrivere codice che usi direttamente le syscalls e che giri 
su BSD e su
Linux, se non con dei bellissimi #ifdef
b) Linux ed i BSD hanno anche altre cose diverse: il sistema di boot, il 
sistema di
configurazione, le convenzioni sui nomi dei dispositivi.

 Ma ci sei o ci fai il sistemista ?
ci sono e ci faccio.
Come va con i mitili? Annata buona? 
p.s.: l'altro giorno ho visto i tuoi fake nei forum di psp-ita. Sono 
mitici: tu fai il post, tutti che dicono ma a che serve st'accrocchio, e 
di nuovo tu ritorni mascherato a tessere le lodi dell'accrocchio.
Uno spasso. Continua cosi'.


Caro Max, ti posso assicurare che i post che vedi non sono fake, ma la
pura realtà, smetti di offendere la gente che ha buona volontà,
piuttosto riguardati tu, che forse sei un po troppo invidioso. Ti
posso assicurare che Filippo è una persona seria, molto seria, la
conosco di persona e ti posso assicurare che non ci sono assolutamente
fake.
Ti ripeto, la tua dose di invidia è eccessiva... quindi vattene a
spammare da un altra parte e su cose che almeno con un po di buona
volontà riusciresti a capire.
Ciao Filippo, non ascoltarlo e contnua così ;)
Max_Adamo ha scritto:


Caro Max_Adamo, sono dello staff del sito PSP-ITA.
Sto vedendo tutti i tuoi messaggi stupidi e invidiosi. Ma perchè
continui a sparare ca**ate di cose che secondo me non hai nemmeno idea
di cosa siano.
PSP-ITA non pubblica mai fake, MAI. Nanodesktop è un progetto alquanto
avanzato e in tutta la scena psp non ho mai visto niente del
genere.Tutto quello che leggi su psp-ita è TUTTO VERO.
Per favore non continuare a disprezzare il lavoro degli altri,
piuttosto cercate di polemizzare il meno possibile.
Arrivederci

 Direi proprio di SI :)
su questo punto occorre dire che viene usato il sistema di init di Gentoo 
e non quello di FreeBSD.
Ma ovviamente, come tutti sanno, il sistema di init di gentoo deriva da 
quello bsd.... diciamo che ne e' un sua evoluzione.
Per cui insomma.... la domanda aveva poco senso.
p.s.: hai mai pescato un mitilo ignoto?


caro Max_Adamo.. vorrei solo farti notare che tutte le persone di psp-
ita sono contro l'idea del fake di Pegasus.. e poi non riesco a capire
come puoi affermare che sia fake, quando ci sono le prove!
a prima botta direi che sei un buffone, che tral'altro non ha buoni
metodi per stroncare l'impegno di Pegasus o di chiunque altro..
secondo invece, ti vorrei far sapere che Pegasus non è uno scemo e non
credo interessi che tu critichi i suoi prodotti.. e poi magari ne fai
uso..
per quanto tu possa dire che sia un fake, moltissime altre persone
seguono gli sviluppi e ne godono le potenzialità che sono a dir poco
eccezionali..
l'unico che ci perde in poche parole sei tu.. che fai questo sforzo
per stroncarlo, ma non pensi che in altri forum e quindi moltissimi
utenti (ma anche di più) ci credono anche vedendo con i loro occhi le
caratteristiche davvero speciali di Nanodesktop..
ma fammi il favore vah!

 e ti posso assicurare che non ci sono assolutamente fake.
facciamo finta di parlare con un non-fake: ah, quindi e' impossibile che 
una persona si registri piu' volte? Potete mettere la minchia sul fuoco 
su questa cosa?


 PSP-ITA non pubblica mai fake, MAI.
come ho detto al tuo collega (ammesso che trattasi di persone 
differenti): mettici la minchia sul fuoco su questa cosa, e garantiscimi 
l'impossibilita' di registrarsi con 2 nick differenti.



CRETINOOOOOOO
SIAMO IN QUESTO MOMENTO IN CONFERENZA SU MSN
E RIDE DI TE MEZZA COMUNITA'
PERCHE' NON VIENI ?
nanod...@hotmail.it


IN FRETTA, SISTEMUNCOLO, CHE I MIEI AMICI
DEVONO ANDARE A DORMIRE.....



sono ospite della chat-room .... mammamia.
Cose turche!!!


 Cose turche!!!
Stiamo massacrando Adamo.
Venite, venite.
Vi prometto un report completo.
NGW, se ci sei, vieni. Questa non-te-la-devi-perdere

 NGW, se ci sei, vieni. Questa non-te-la-devi-perdere
oddio ... mi manca solo il suo "massacro".


 caro Max_Adamo.. 
dav_91 ???? 91 ??? novantuno?
cioe' hai 16 anni?
Fili', riportali a dormire prima che si fanno pipi' addosso.


 Caro Max_Adamo, sono dello staff del sito PSP-ITA. 
nightlight90? 90?
Cioe' avresti 16 anni?
Fili', porta pure questo a dormire prima che si fa pipi' addosso.



Siiiii. A tal punto che sei scappato a gambe levate come un coniglio......

 coniglio......
filippo: sono caduto. stavo scrivendo e':
(00:12:29) Il messaggio non è stato inviato a causa di un errore di 
connessione:
comunque sei un degenerato: mi hai portato i tuoi cuginetti, 
rispettivamente di 15 e 16 anni (dav_91 e nightlight90), col rischio di 
farti sgridare dai tuoi zii.



Strano, a me dai log non risulta.....
Ma magari puoi andare su psp-ita e postare nella sezione programmazione.
Dì così:
"Dite la verità: Nanodesktop non esiste e Pegasus ha 30 fake su 3 NG
diversi".
Così magari le risate si sentiranno negli Stati Uniti.....
Facciamo così ? Ed io magari faccio un report completo delle risposte
(e delle risate) qui su it.comp.os.dibattiti.
Può essere interessante ......

 gli altri 3 assolutamente no.
vero, ma per tutto il resto sono uguali.

 una unica coda a velocità piena.
Sei sicuro di stare rispondendo a me? Perchè qui non stavamo parlando di
efficienza, ma del fatto che Hurd in buona sostanza non funziona.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 Lo avevo letto e mi interessava! Come mai è defunto?
Perchè ad Apple non interessava più. Quegli altri non so perchè lo hanno
mollato. In realtà credo che qualcuno faccia ancora delle patch, ma
insomma, non lo usa nessuno e non fanno release da anni.


 curiosità: hai aggiornato al 10.4.10?
Si. Il mio newsreader mostra sempre 10.4.9 perchè usa un'API anziana e
deprecata da tempo che non mostra le minor version a due cifre. Assurdo,
ma vero.


 microkernel in partenza: un kernel XNU Mach.
Definisci il concetto del 'kernel di un BSD'.


 univocamente i concetti.
Allora comincia a dare le definizioni. Come ti dico, poco cambia. Dire
BSD, BSD Environment o quello che vuoi per me non è particolarmente
rilevante dal mio punto di vista. 
Il punto è che nella famiglia dei sistemi *nix like OS X sta
evidentemente dalla parte dei BSD sotto moltissimi punti di vista. Il
resto è, come dire, una questione terminologica.


 rilevante dal mio punto di vista. 
ok, allora secondo me dire che sia un bsd o che fornisca un ambiente
comptibile a bsd sono due cose diverse. Perché io intendo che un bsd
condivide anche l'architetture di bsd.

 efficienza, ma del fatto che Hurd in buona sostanza non funziona.
tu hai scritto che può essere un errore di design. Io ti ho detto che è
proprio quello. E che è pure dimostrato matematicamente.

 roba.
mi rispiego: una delle grosse critiche al monolitico è che se si bomba
una cosa si bomba tutto. Però un idle task monolitico su un microkernel
non elimina il problema. Capisci?
L'approccio di hurd risolverebbe il problema, peccato che sia un
approccio che non corre.....

 wikipedia). E siccome nessuno implementa tutto allora nulla è uno unix.
ah, ok. qui viene semplicemente fuori la mia ignoranza in materia, ho fatto
una supposizione errata. ma comunque era una battuta :P
-- 
NoWhereMan (e.v.)
-- 
http://www.nowhereland.it
-- 
http://flatpress.nowhereland.it

 insomma, non lo usa nessuno e non fanno release da anni.
un vero peccato


 Caro Max, ti posso assicurare che i post che vedi non sono fake,
Resta sempre il dubbio del come mai spuntano fuori tre
tizi,
- dav_91
- iliornoelanotte
- nightlight90
con un nick _*MAI*_ apparso su usenet, lo stesso giorno,
che rispondono alla stessa persona, con argomentazioni simili.
Viene da chiedersi: come cazzo facevano a sapere
che Mr. Max_Adamo stava perculando Mr. Pegasus
senza essere lo stesso Mr. Pegasus con il vizietto
del fake?
Ma probabilmente tutto si puo' spiegare con la teoria
dei "grandi numeri", oppure come mi ha risposto
google.groups quando ho provato a vedere chi si celava
sotto 
dav...@hotmail.it
http://img292.imageshack.us/my.php?image=captchacw7.jpg
Manco google crede che 'sti tizi siano veri... :-)
C:\>iao Angelo


Ecco l'altro grande intellettuale incompreso di ICOD.....
Eravamo su MSN tutti e tre in connessione, quando Max ha scritto
che su psp-ita erano tutti miei fake.
E sono stato io a chiedere loro di venire qui, e di spiegare la situazione,
perchè così Ada avrebbe avuto qualche prova e si sarebbe stato
zitto finalmente.
Poi, visto che Ada si è inventato che Davide e Vinchent sono miei fake,
l'abbiamo invitato su MSN ed ha visto i 3 personaggi di cui sopra
tutti e tre in connessione contemporanea, ha controllato gli IP e
venivano tra 3 punti diversi (Roma, l'Aquila e Catania), ed è stato
preso per scemo tra tutti, tantovero che è scappato a gambe
levate.
Questi tizi sono così inesistenti, che su psp-ita li trovi tutti e tre.
Uno è addirittura il mantainer del sito.
Altre fantasie da sviluppare ?

 Altre fantasie da sviluppare ?
Ah! Quindi hai gentilmente chiesto agli amichetti di scrivere qui
per dimostrare che esisti e che non sei una serie di slide
PowerPoint...
Lo sapevo che c'era una spiegazione, belin!. :-DDD
C:\>iao Angelo

Lo sapevo che c'era una spiegazione, belin!. :-DDD
Solo come reazione ad un fesso totale (tuo compare....) che
affermerebbe che io tengo 51 fake su 5 siti tra italia, spagna,
francia e stati uniti.
Facendo ridere il mondo intero a reti unificate......

 Facendo ridere il mondo intero a reti unificate......
:-)
C:\>iao Angelo

 scatenare un mega flame
Come volevasi dimostrare. A parte qualche interessante spunto iniziale, alla
fine centinaia di messaggi su BSD ce l'ha pių lungo di linux, che perō ha
pių donne di BSD...
In fondo, ma speravo qualcosa in pių, uno spunto l'ho avuto: tante guerre di
religione fra i vari progetti! :D

 religione fra i vari progetti! :D
Io un suggerimento te l'ho dato: leggersi quualcosa di detto
direttamente da chi l'OpenSource lo prende seriamente.
Qui ogni tanto qualcosa di serio si dice, ma spesso il serio che
si dice e' annegato in un flame.
C:\>iao Angelo

 Definisci il concetto del 'kernel di un BSD'.
semplicemente: un kernel monolitico.... visto che i *BSD hanno tutti tale 
kernel.
Anche se capisco il tuo discorso di cui sopra per cui: non  sarebbe un 
kernel che fa un BSD.


 direttamente da chi l'OpenSource lo prende seriamente.
In tutta onesta, il libro lo avrei procurato e letto se solo l'esame fosse
stato più distante nel tempo... Come avrei letto "The cathedral and the
bazaar", che a questo punto scorrerò molto velocemente.

 variare la fauna che frequento di solito....
R O T F L
-- 
BArrYZ

 proprio quello. E che è pure dimostrato matematicamente.
Non ci siamo capiti: non è che il microkernel non funziona perchè non
può funzionare. Ci sono microkernel che funzionano eccome.
Per cui il fatto che Hurd non funzioni in buona sostanza è dovuto ad
altre ragioni.
Il discorso sulle dimostrazioni è semplicemente una questione di
*performance*. E il problema di Hurd non è solo che è lento. 


 kernel che fa un BSD.
Esattamente. In se e per se è un 'accidente' storico che siano tutti
monolitici. Per esempio DragonFlyBSD sta incorporando primitive tipiche
di un microkernel. Chissè che in futuro...
Poi la storia fra Mach e BSD e lunga. Pensa che Mach stesso è stato
creato per sostituire il kernel della Berkley Software Distribution. E
Mach era un microkernel *puro*.
Nota che a sua volta la gestione della memoria di Mach si è fatta strada
dentro i BSD (e che in effetti Mach stesso è nato come codice aggiuntivo
a BSD, hostato nello stesso server).
Per inciso BSD 4.4 usava il sistema di VM di Mach. NetBSD si è
distaccato creandosi il suo uvm, mentre FreeBSD è rimasto a lungo con
quello. Adesso non saprei dire se le modifiche sono sufficienti per dire
che usa *altro* o che ne è solo l'evoluzione.


 approccio che non corre.....
Al di la di tutto il grosso problema del microkernel sono le features di
sicurezza implementate sui singoli messaggi. Uccidendo quelle (e altre
cose) si corre eccome -- leggi L4 --.


 condivide anche l'architetture di bsd.
Ma la cosa critica di BSD non è il Kernel: è il *sistema* *operativo*.


 altre ragioni.
è dovuto ai multipli serventi. ed infatti tutti i microkernel che
funzionano ne hanno uno solo.
Ci capiamo?

 cose) si corre eccome -- leggi L4 --.
l4 è superiore a mach, fuori da ogni dubbio. paga lo scotto di essere
fortemente ottimizato per i386 e x86_64, quindi la sua portabilità non è
immediata e senza eprdita di prestazioni.
Ma quello che to cercandodi spiegarti è che non è il problema del
microkernel ma di avere 1 o n serventi (o translator per dirla alla hurd)

 si chiama Berkely *Software* Distribution.
Guarda Enrico, ho capito che seiun fan di mac os x. Anche a me piace,
però qui ti stai arrampicando sugli specchi per far passare una (buona)
cosa per quello che non è.

 cosa per quello che non č.
Non vedo cosa c'entra essere o meno fan. MacOS X mi piace che sia o meno
BSD. Non lo vedo come un merito ne come un demerito. 
Come ti ho detto un po' di tempo fa, č questione di etichette. Per te
quali sono le condizioni per essere considerato un OS della famiglia dei
BSD?


 microkernel ma di avere 1 o n serventi (o translator per dirla alla hurd)
Si. Anche se il problema di cui ti parlo è in se non rilevante. Una
chiamata di sistema su Mach impiega qualcosa come un ordine di grandezza
in più rispetto che su L4 (se ricordo bene).
Quello che dicevo su Hurd è che anche se fosse l'OS più veloce della
terra, avrebbe fallito perchè non se lo sta cagando nessuno. Il punto è
che per lungo tempo più ancora che lento è stato buggato un casino.


 Ci capiamo?
Ora si. Stavamo facendo due discorsi diversi.


 microkernel.
hai un link? perché cercando su google non ho trovato nulla, se non
questo vago discorso che però è più contro che pro i microkernel.
http://leaf.dragonflybsd.org/mailarchive/kernel/2003-10/msg00019.html

 BSD?
te ne cito tre che mach non ha: monolitico, ipc basate su syscall,
grande uso del filesystem come namespace e meccanismo di controllo di
accesso alle risorse.

 in piů rispetto che su L4 (se ricordo bene).
tra parentesi, una syscall in l4 č 22-23 volte piů veloce in mach.
Peccato perň che per ottenere questo risultato ci siano delle carenze:
l4 non gestisce il controllo di accesso alle porte e lo delega ai programmi.

 questo vago discorso che però è più contro che pro i microkernel.
Non è questione di microkernel vs. kernel monolitico. Come ti dicevo
vedo una convergenza al centro. 
E in quel link parla appunto di 
" What we can do is move the bottomost layers, primarily device drivers,
    the networking layer, and filesystems, towards a microkernel-like
    message-passing design. "
ovvero non sto dicendo ne che DF-BSD sia un microkernel ne che lo
diventerà. Ma che stanno venendo presi alcuni degli aspetti di un
microkernel e messi in un kernel monolitico.
In questo senso vedo convergenza.


 l4 non gestisce il controllo di accesso alle porte e lo delega ai programmi.
Infatti. Ma questo potrebbe non essere un problema su un oggetto
embedded chiuso, dove i programmi possono essere considerati 'sicuri' by
default.


 accesso alle risorse.
In primo luogo la richiesta che il kernel sia monolitico è una richiesta
tua ad hoc. Non c'è scritto da nessuna parte. Anzi, Mach era nato
proprio per sostituire il kernel originario della berkley software
distribution (e non lo ha fatto principalmente perchè troppo lento).
Le IPC basate su syscall sono *tutte* presenti su OS X. E sono anche,
per inciso, il modo principale di lavorare. Chiamare direttamente le API
di Mach, anche se possibile, non viene fatto praticamente *mai*.
Come sopra per il filesystem.
Poi ripeto, se ti fa piacere che OS X non sia un BSD, non cambia nulla
per nessuno. 


 
ma io alla fine della mail vedo anche
Nor would I particularly want to try.  I see no advantage at all in
trying to convert the system wholely to a microkernel design, other then
to slow it down and make the source code harder to understand
quindi io questa convergenza non la vedo...

 default.
ok, anche se imho è uno scenario restrittivo

 per nessuno. 
non lo afferma neppure apple. Tu hai il difetto di capire più di quello
che c'è effettivamente scritto quando leggi. Loro dicono che hanno preso
molto da bsd, non tutto. Dobbiamo passare agli insiemi per concordare
che non è una uguaglianza?

 che non è una uguaglianza?
Ottavio, il ragionamento non è molto sensato perchè non tiene conto
di come funziona internamente OSX. Il funzionamento è non molto
diverso da quello che usa Microsoft con i suoi sistemi NT.
Se ti ricordi, NT 4 era compatibile con OS/2. E nello stesso tempo
anche con Win16 e con le applicazioni Win32. Perchè ?
Perchè le applicazioni parlavano non con il kernel principale, ma con
il loro sottosistema, che successivamente traduceva le chiamate in
un layer comune comprensibile al microkernel centrale.
Nel caso di OSX, si tratta di un BSD per due ragioni:
a) intanto perchè è compatibile con il modello di chiamata delle syscalls
dei BSD, che è ****diverso**** da quello di Linux. Pertanto trattasi
di BSD perchè le syscalls sono quelle dei BSD.
b) poi perchè il file system space segue le convenzioni sui dispositivi che
sono tipiche dei BSD (e che sono, ancora una volta, diverse da quelle
di altri Unix come QNX o Linux).
Tutto qui. Poi le applicazioni OSX eseguono chiamate stack-based (ossia,
chiamate BSD), che vengono tradotte in chiamate compatibili con il
microkernel Mach/XNU. Ciò non toglie che, al di là della differenza di
implementazione interna (che ti ripeto: non rientra fra i requisiti per
definirlo o non definirlo un BSD, ma è del tutto libera....), trattasi di
BSD perchè può eseguire codice binario che usa le syscalls BSD.

Manuel T ha scritto:

puoi dare anche un'occhiata a "codice libero" di Stallman
-- 
|L|E|L|E|

 syscalls dei BSD, che è ****diverso**** da quello di Linux.
Questa proprio non va bene.
Qualcuno ha mai detto che MacOSX e' un Linux? :)
Mi spiego meglio: il fatto che una ferrare sia diversa da un 500 non e' 
sufficiente per dire che una ferrari e' uguale a una land rover.
Devi dimostrare l'uguaglianza con BSD e non la differenza con Linux.


 l'aggiunta di portage e altri toolettini di gentoo.
Direi che qui hai appena scritto che *non* č FreeBSD.
Č il *kernel* di FreeBSD. Sarebbe un 'GentooBSD' o che so... altro nome.
Esattamente come esiste Debian NetBSD (che non č NetBSD) e cosģ via.
FreeBSD č tutto un sistema operativo. Se prendi il kernel di freebsd e
lo metti dentro Gentoo, hai magari un oggetto bellissimo, che perņ non č
FreeBSD.
In questo č diverso da Linux dove Linux č appunto solo un kernel.


 (da fedele maintainer Debian, porto avanti la mia bandiera :-P)
Si, ma ancora una volta *non* sono NetBSD e FreeBSD. Ne usano il Kernel.
Sono distribuzioni *Debian* (non Berkley Software Distribution) che
usano il kernel di Net e FreeBSD.
Senza per questo dire che siano cattive cose, solo sono cose a se
stanti.


 quindi io questa convergenza non la vedo...
Non vuole dire che un kernel monolitico *diventa* microkernel o
viceversa. Vuole dire che gli uni incorporano caratteristiche degli
altri per aiutarsi a far fronte ai proprio punti deboli.
Detto questo, non ho molto da aggiungere.


 ok, anche se imho č uno scenario restrittivo
Ristretto piů a meno alle varie fotocamere, elettrodomestici,
determinati cellulari, videoregistratori e simili. Boh, a me sembra un
mercato vastissimo, ma ognuno ha la sua prospettiva.


 definirlo o non definirlo un BSD, ma è del tutto libera....),
no, questo è il punto. non è libera. Ci sono libri e articoli che
definiscono cosa sia BSD, non è una cazzatina lasciata all'immaginazione
della gente. Non è una roba che mi sono inventato io (magari, ci
metterei la firma per essere del calibro di ritchie o bach).

 In questo è diverso da Linux dove Linux è appunto solo un kernel.
Enrico, premetto che non ho grossissima esperienza perche' non l'ho mai 
installato. Rispondo per quello che leggo sulla documentazione, e in base 
ai pacchetti disponibili che trovo in portage.
Credo che non si tratti del solo kernel, ma del kernel e di *tutti* i 
tool di FreeBSD.
Quindi In sostanza e' un FreeBSD + portage + sysinit di Gentoo.
Cos'e'? Come lo vogliamo chiamare?
Consideriamo che:
portage deriva dal sistema dei ports di BSD
i sysinit di gentoo sono una evoluzione di quelli BSD.
Pertanto: dobbiamo veramente porci questa domanda? Non siamo a livello di 
cavilli sottilissimi cui non ha senso nemmeno cercare una risposta?
Due fratelli gemelli non sono la stessa persona, pero' ca$$o se si 
assomigliano.


 parte per i driver)
E' inutile, gli e' stato spiegato 800 volte, ma non sa un cazzo e capisce 
meno.
E poi scappa.
  ngw
-- 
"ma gavte la nata." -- Jacopo Belbo
http://www.tochunky.org

 unix o unix-like ?
Cazzo c'entrano le ACL ora, santiddio ? :D


 Un bsd Ãš un kernel fatto in una cera maniera. e basta.
Ahhhhh, la trama si infittisce, visto che nessun BSD e' un kernel !!!
E quei coglioni che guardano centovetrine :D


 Lo avevo letto e mi interessava! Come mai Ãš defunto?
Gli sviluppatori si sentivano seguaci di tanenbaum e sono usciti dall'eresia 


):

Al di la' del fatto che ho grossi dubbi che Ritchie abbia scritto di BSD - 
almeno non nei libri che ho io - la tua "lista" di features che il *kernel* 
di un BSD (e ripeto non si fosse capito, nessun BSD e' solo un kernel, ma e' 
evidente che tu solo quello consideri) dovrebbe per te avere.
Visto che la metti cosi', OS X e' per riflesso un derivato di BSD, ha nel 
kernel una tonnellata di codice da FreeBSD e da BSD 4.4.
E poi c'e' lo userland che praticamente e' in comune al punto che OS X ha 
parti di FreeBSD placidamente non funzionanti (come chiunque si sia 
installato il memcached di un paio di versioni fa sa, visto che scazzava 
miseramente in performance esilaranti perche' la Apple ha sputtanato kqueue e 
libevent andava in puppa).
E qualche ovvieta', come i progetti in comune che Apple nella sua benevolenza 
finanzierebbe pur avendo queste _profonde_ differenze architetturali che 
chiaramente le rendono questi progetti inutili (ma invece, incredibboli, 
qualcosa ci fanno, anzi pare che portino roba da una parte all'altra nel 
tempo di un peto). O i bug, spesso in comune, ricordo una privilege 
escalation per via di shmat(2), che non mi pare esattamente printf.
Poi libero di prender un BSD, segarne 4/5 e ragionare su quelli e su un libro 
di Ritchie, io mi fido dell'Apple BSD Technology Group.
Siccome nessuno e' pagato per convincerti, facciamo che non e' un BSD, ma un 
sistema operativo diverso, io restero' a chiedermi com'e' che fai a 
comprendere cosi' bene l'architettura dei BSD usando un testo di 4 anni piu' 
vecchio del piu' vecchio dei BSD di cui stiamo parlando (OS X non lo nomino, 
che gli anni diventano 15).


 vero, ma per tutto il resto sono uguali.
Ah cazzo, figo.
Insomma, alla fine Linux e' un BSD no ? 
Voglio dire, VM differenti, scheduler differenti, girano o non girano su SMP 
chi cazzo se ne frega, Giant Locks ovunque in OpenBSD e NetBSD i miei 
coglioni, stack TCP/IP differenti amen.
Evvai cazzo, mo' abbiamo il 7.7% di installato ! :D


 cavilli sottilissimi cui non ha senso nemmeno cercare una risposta?
Si. Siamo a livello di cavilli. Ma è tutto il thread che cerchiamo di
depilare le mosche. :)




un giorno ti faro' fare la fine del grillo parlante :)


 depilare le mosche. :)
eh, pero' se vogliamo cavillare, c'e' una cosa che stride a questo punto:
-> GentooBSD abbiamo detto che e' un freebsd + portage + sysinit di gentoo
-> MacOSX abbiamo detto che e' (sommariamente) un kernel xnu mach + tool 
BSD + software proprietario.
Perche' MacOSX sarebbe un BSD e gentoobsd invece no?
Io vedo in MacOSX molta piu' roba differente rispetto a FreeBSD, che non 
su Gentoo.


 Un BSD e' un derivato di BSD.
e un BSD, con tutti i tool di FreeBSD e l'aggiunta di portage cos'e'?
http://www.gentoo.org/doc/it/gentoo-freebsd.xml


 che e' un BSD, tendo a fidarmi.
Oste, avete vino buono o vino che fa schifo?


 
http://www.gentoo.org/doc/it/gentoo-freebsd.xml
Un BSD.


 su Gentoo.
Probabilmente non ci è chiaro *esattamente* cosa è in 'GentooBSD'. Da
come avevi scritto tu a me era parso di capire che fosse semplicemente
il kernel di FreeBSD e poco altro messo dentro Gentoo. Il che, usando la
definizione di rms, darebbe luogo a GNU/FreeBSD (ammesso che il kernel
di FreeBSD non abbia un suo nome vero e proprio, nel caso sarebbe
GNU/etc etc etc).
MacOS X invece rispetto agli altri BSD ha certamente delle differenze,
ma al di la di quello che gira negli strati superiori (che è
estremamente poco rilevante), non è molto più diverso da un generico
*BSD di quanto i vari *BSD siano fra loro. 
Ribadisco, l'implementazione *interna* del Kernel per me (e per la
maggior parte degli utenti di BSD) non è particolarmente rilevante, come
non è rilevante per chiamarsi *nix. MacOS X ha l'userland di un BSD,
buona parte del kernel preso proprio da FreeBSD *e* viene usato come un
FreeBSD. 
Ottavio invece la pensa diversamente. Lui guarda il *tipo* di
implementazione del Kernel. IMHO per definire una cosa che si chiama
*Software* *Distribution* il sistema di meccanismo delle syscall non è
particolarmente rilevante (anche perchè dalla mia ultima lettura di
MacOS X System Internals mi pareva proprio che le syscall BSD non
venissero fatte allo stesso modo delle syscall Mach, dovrei
approfondire, se considerassi la faccenda rilevante).


 piattaforma VAX :)
s/VAX/PDP-11

 Esiste una Lada Niva con motore Ferrari (giuro!).
Subito credevo che ti confondessi con l'LM002, invece incredibile, č tutto
vero!
http://video.google.com/videoplay?docid=1162625403634678695
http://video.google.com/videoplay?docid=6537105651095354850
ROFL.
-- 
emboliaschizoide.splinder.com

 ROFL.
haha: mitico il sorpasso sulla toyota che prova a fare la salita 4 voltee 
arriva la Lada che gli zompa quasi di sopra.
Visto che ci siamo: esistono pure la 5 porte allungata e la pickup. Ma 
queste sono VAZ AutoLada Toliatti (*) originali di Toliattigrad
http://www.belaruscar.it/LADA.FUORISTRADA.NIVA5PORTE.htm
 
Visto che ci siamo questa invece e la mia:
http://maxadamo.homelinux.org/jalbum/personali/AutoLada%20-%20Togliatti%
20-%20(mag.%202003)/index.html
:P :P
sorry per la l'URL suddiviso.
 
(*) e la traslitterazione russa di Togliatti


 :D
LOL :D
-- 
NoWhereMan (e.v.)
-- 
http://www.nowhereland.it
-- 
http://www.flatpress.org

 (permessi, utenti) che rende un sistema operativo un BSD.
si riferiva a qualcos'altro?
ciao :)


 20-%20(mag.%202003)/index.html
Non fanno più le auto di una volta... per fortuna. Però devo ammettere che
il sedile bicolore fa molto racing. :-))
Una curiosità (non mi intendo molto di fuoristrada in generale): un pomello
è il cambio, un altro pomello è per le ridotte, ma il terzo? E' il pomello
che agevola il glorioso avanzamento del comunismo? :)
-- 
emboliaschizoide.splinder.com

 Un BSD.
eccola conseguenza di una definizione sbagliata.
Per inciso, sono contrario alla sega di dire che linux sia solo un
kernel. Il discorso che a differenza di altri s.o. non c'è un gruppo che
gestisce il core ma un gruppo che fa il kernel e anti altri gruppi che
fanno altre cose causa una distinzione che alla fine fa incappare in
queste discussioni/definizione del cavolo.

 Cazzo faccio prima a dire le parti uguali :D
il design, ma forse non hai il dono della sintesi.

 che gli anni diventano 15).
il motivo è molto semplice: un libro buono spiega i concetti che ne
stanno alla base. non sarà cutting edge, ma la chiarezza imho viene
prima di tutto.

 Insomma, alla fine Linux e' un BSD no ? 
direi di no, basta che guardi la gestione dei processi in linux e in bsd.

 prima di tutto.
Senza dubbio. Pensa che io tutt'ora mi riferisco a Unix Network
Programming *prima* edizione, non il mastodonte in due libri che hanno
fatto poi (che è scomodo da portarsi in giro e sono molto più
familiare). Tanto per alcune nozioni aggiornate, di recente ho comprato
la seconda edizione di Advanced Programming in the Unix Environment. Ma
alla fine se ho un qualche dubbio è molto probabile che cerchi prima su
UNP (a meno che non sia in uno di quegli argomenti trattati di
sfuggita).
Ma il punto non è questo. Il libro si riferisce a BSD 4.4 (se è quello
che dico io). Si riferisce quindi a un perioso quando BSD era anche *un*
sistema operativo (precisamente BSD4.3 e poi BSD4.4), non solo *una
famiglia* di sistemi operativi. Ragione per la quale non prende in
considerazione quali siano le caratteristiche che rendono tipico un BSD.
Il problema non si pone tanto.
Per cui è ovvio che tratti di come funzionino le cose in BSD4.4. Ma
questo non vuole dire che per fare parte della 'famiglia' dei *BSD
(famiglia tra l'altro non caratterizzata da dizioni formali) bisogna
mantenere intatto il funzionamento di BSD4.4. Anche perchè si rischia
che prima o poi qualcuno dei quattro BSD da te ufficialmente
riconosciuti si scopra non essere più BSD. :)


 riconosciuti si scopra non essere più BSD. :)
ok, ovvio che con la flessibilità mentale di un batolite di granito non
si va da nessuna parte. Però secondo me basarsi sullo scambio si
messaggi invece che sulle chiamate a sistema è già una grossa
differenza. Poi esponi una api simile e va benissimo, ottima scelta, ma
non reputo sia sufficiente per definirlo un bsd.
Insomma, per sprecare un minimo di filosofia ultraspiccia, tra apparire
ed essere c'è una bella differenza.

 eccola conseguenza di una definizione sbagliata.
ma mi sa che ngw qua scherzava, sai?


 ma mi sa che ngw qua scherzava, sai?
non ho visto la faccina... :-O



aahh .... dale parti di togliattigradi, una ne sanno e cento ne inventano.
Ti svelo il segreto del terzo pomello: bloccaggio differenziale :P
Tecnicamente parlando, nella macchina di un comune mortale, quando una 
delle ruote inizia a slittare, il differenziale si adegua (pensando che 
sei in curva) e la ruota dall'altra parte non gira per nulla.
In questo modo il differenziale viene by-passato.
ti dico comunque che il meccanismo non e' perfetto. Una volta sono 
rimasto con una ruota penzoloni fuori dalla strada. Ho provato a bloccare 
il differenziale ma non ha funzionato come avrebbe dovuto :(
forse con la ruota completamente libera non funziona del tutto e in 
realta' riduce solamente l'azione del differenziale ma non la elimina del 
tutto.
A questa stronzata si aggiunge il fatto che se va completamente fuori una 
ruota posteriore, sulla Lada non puoi disinserire le 4 ruote motrici e 
venirtene fuori con le ruote davanti :(


 ma mi sa che ngw qua scherzava, sai?
non credo proprio.
D'altra parte, e' assolutamente insostenibile dire che MacOSX sarebbe un 
BSD e gentooBSD invece non lo sarebbe.
Su cosa ti baseresti per affermare una cosa del genere... visto che 
gentooBSD, portage a parte, e' un BSD a tutti gli effetti, e visto che 
MacOSX non usa nemmeno il kernel di freebsd.
Portage e' un set di script in python e non credo che l'aggiunta di un 
set di script per installare i pacchetti, puo' stravolgere tutto.


 non reputo sia sufficiente per definirlo un bsd.
Quello che voglio dire è che lo scambio di messaggi in OS X c'è. Ma
spulciando OS X System Internals non mi pare affatto che tale meccanismo
sia usato dalle syscall BSD. In effetti ci sono *due* capitoli distinti
che affrontano il funzionamento interno delle syscall di stile BSD e di
quelle Mach.
Ora in questo periodo sono super impegnato e dovrei spulciarmi per bene
quanto ho accennato per esserne sicuro (ed è un librazzo di circa 1000 e
passa pagine, anche se le zone dove ne parla sono molto meno, Singh ha
cercato di essere più esaustivo e dettagliato che coinciso -- e d'altra
parte c'era bisogno di un libro come il suo, che spaccasse il capello in
quattro).


 il design, ma forse non hai il dono della sintesi.
Cazzo, per come sei partito sembrava quasi volessi dire qualcosa :D


 quelle Mach.
ti dico, dal poco che ho letto io avevo capito che le syscall vengono
tradotte in scambio di messaggi all'interno del kernel. Poi, ti dico
pure che io i sorgenti non li ho mai visti, quindi....

 questo mi sembra un sofismo di scarsa utilità
Mica tanto, il sofismo equivalente e` come un motore (e basta) ed una 
automobile intera.
-- 
Sensei <senseiwa at Apple's mac dot com>
Error. Keyboard not attached. Press F1 to continue...
(Real BIOS Error)

 automobile intera.
senti se dobbiamo confrontare 2 automobili, non possiamo prendere da una 
parte una automobile nella sua interezza, e da un'altra parte un'auto che 
per una definizione voluta da qualcuno risulta essere composta solo da 4 
ruote, sedile e un tergicristallo..... dove gli altri sedili, il motore, 
i cristalli e la carrozzeria sarebbero lo userland....
Bisogna confrontare cose uguali. punto e punto :P 
quella definizione e' fine a se stessa.


 Bisogna confrontare cose uguali. punto e punto :P 
Ma non è che si sta facendo confronti fra Linux (che è in se e per se un
kernel[0]) e BSD che è un sistema operativo.
Si stava confrontando una definizione di BSD basata sul kernel (ovvero
su una sola parte, parecchio diversa per inciso fra i vari membri
'indubbi' della famiglia) con OS X (ovvero un sistema operativo).
----
[0] poi quando la cosa non è ambigua mi capita di dire Linux anche per
indicare tutto un sistema operativo basato su Linux. Secondo rms dovrei
dire rms, normalmente lo faccio, alcuni non sono d'accordo, ma IMHO
questi sono *sofismi*.
Esattamente come può capitare di chiamare FreeBSD il kernel di FreeBSD
(quando questo non genera ambiguità), anche perchè non so se ha un nome.
Su OS X è un casino. C'è MacOS X, DarwinBSD e xnu.


 questi sono *sofismi*.
dici rms/linux ? :P


 dici rms/linux ? :P
eh...
