Newsgroup: it.comp.os.dibattiti
Titolo: Linux VS altri OS

Tutti noi[1] concordiamo su di una cos: che linux senza un'adeguata API
stabile per i driver di terze parti non farà molta strada. Ma gli altri
sistemi operativi (eccetto windows), da questo punto di vista, come sono
messi? Mi riferisco soprattutto alla famiglia dei *BSD, che è quella che
alla fine può dare più filo da torcere a linux
Henryx


cd /pub
more beer


dipende. Se i driver sono opensource il problema dell'abi si risolve con
una compilazione. Le api non cambiano poi cosi' spesso.
Vorrei dire una cosa: leggevo proprio ieri nelle faq di openbsd che loro
non hanno il minimo interesse a realizzare una infrastruttura di
caricamento moduli come quella di linux, che permette a tutti di
attaccare moduli con varie licenze.

 attaccare moduli con varie licenze.
Questo a mio avviso e` buono: scelte forti in favore di stabilita`... 
certo, openbsd e` intransigentissimo in fatto li licenza, tanto da aver 
eliminato apache...


 eliminato apache...
eh!?!? cazzarola, nei port del 3.7 e' vero non c'e'..... ma hanno roba
non free come jre.... Come mai?

 non free come jre.... Come mai?
Bho... licenza troppo restrittiva dicono... poi... bho! Potrebbero 
anche ritenerlo instabile ed insicuro per i canoni loro.


 nel source tree del kernel.
Aggiungo una cosa: una compatibilita` binaria e` molto facile in C, 
piu` difficile in C++, se vuoi sapere come fanno e` facile:
http://developer.kde.org/documentation/library/kdeqt/kde3arch/devel-binarycompatibility.html
( 
http://tinyurl.com/cepw9
 )
saltando le parti C++ puro, ovvero classi, privatezza & co.


 nel source tree del kernel.
non capisco cosa vuoi dire. Intendi elf?
Io intendi il formato per esempio dei moduli, che cambia e per questo
motivo e' necessario aggiornare le modutils.

 
http://developer.kde.org/documentation/library/kdeqt/kde3arch/devel-binarycompatibility.html
ok ok. su questo concordo. Ma questo non e' un problema di kernel di
linux :-)
Tra parentesi, contribuiscono bene sia le modifiche dell'abi del c++
(vedi l'ennesima modifica introdotta da g++ 4.0) e le idee stravaganti
di Stroustrup sulla prossima versione del c++, che se non cambia idea si
chiamera' c++0x 
http://www.research.att.com/~bs/rules.pdf

non free come jre.... Come mai?
http://www.openbsd.org/policy.html
Se non ricordo male Apache fa parte dell'installazione base, e nei
pacchetti dell'installazione base non è ammesso codice con licenza più
restrittiva della BSD.
"As a consequence, OpenBSD now maintains its own version of Apache
based on version 1.3.29. The OpenBSD version includes many
enhancements and bugfixes."
Stessa cosa se si va a leggere la parte riguardante GPL.

 chiamera' c++0x 
http://www.research.att.com/~bs/rules.pdf
Ma dai...
0x sta ad indicare la prossima revisione del c++.
Così come ci sono il C89, il C99, il C++98, ci sarà il C++0x (x perché 
non si sa ancora in che anno).
Ciao.


ah in quel senso..... Cavolo, non c'ero arrivato... io pensavo al
prefisso 0x dei numeri esadecimali... Mi sembrava un nome insulso....

 chiamera' c++0x 
http://www.research.att.com/~bs/rules.pdf
Compe il C90, F77, C99, F2000... indica l'anno dell'ISO :)


 
Intendo il fatto che un kernel di una subsottoversione sia compatibile 
con quella precedente & successiva, permettendo ad esempio l'uso di 
moduli binari precompilati non buttandoli al cesso ogni volta che 
cambia una virgola. L'esempio tuo e` tra i 2.4 e 2.6 e li accetto la 
non compatibilita` binaria --- piu` o meno, dovrebbero fare sempre un 
wrapper e garantire la compatibilita`, comunuqe...
Tanto, la prima cosa e` che sia compatibile a sorgente. Finche` non lo 
sara` non potra` esserlo manco binario.


 sara` non potra` esserlo manco binario.
1) confrontare l'abi del kernel con l'abi del c++ mi sembra abbastanza
fantasioso.
2) ok, i moduli 2.4 sono diversi da quelli del 2.6, mica serve un genio.
Mai i driver di 95 sono compatibili con quelli di xp? A livello di
sorgenti non lo so perche' non sviluppo per windows, ma nutro seri dubbi....
3) l'onere del wrapper a chi spetta? Come diavolo fanno gli sviluppatori
opensource a fare un wrapper se chi fa il driver non-free non gli da' i
sorgenti? Ma allora, se non dai i sorgenti, se devi comunque metterci le
mani per fare il wrapper, che cavolo fai il wrapper a fare? Sistema
direttamente il driver. Dopotutto, se guardi gli aggiornamenti dei
sorgenti legati al modello dei driver vedi come non e' un'operazione
eccessivamente invasiva, e di solito chi se ne occupa riesce a farlo in
breve tempo per piu' di un driver. Guarda i changelog se non ci credi.

 breve tempo per piu' di un driver. Guarda i changelog se non ci credi.
Il wrapper e` tra le chiamate vecchie e quelle nuove. Invece di buttare 
di sana pianta tutto quanto, si scrive una nuova API, e si mantiene la 
compatibilita` verso il passato. Cavolo c'entra un driver binario con 
le API del kernel? Il driver USA le api del kernel, se queste cambiano 
il driver deve cambiare, non e` il contrario.


 driver deve cambiare, non e` il contrario.
appunto. e allora sono cazzi di chi fa i driver. Una buona parte delle
modifiche dei moduli sono state introdotte per motivi di licenza e per
l'esportazione dei simboli. Ora, siccome queste modifiche sono state
introdotte perche' ci sono autori che non vogliono rilasicare i
sorgenti, saranno cazzi loro di stare al passo, o no?
Dove sta il problema? nvidia ti da' i driver per xp? bene! ti non da' i
driver per linux perche' non vuole scriverli o investirci tempo o
rilasciare le specifiche? bene lo stesso, hanno perso un cliente.

 rilasciare le specifiche? bene lo stesso, hanno perso un cliente.
No, te li da, ma quando ricompili non l'hai piu`.
Tra l'altro, e` *linux* che non prende clienti, questo e` il brutto. 
Non e` certo NVidia che perderebbe milardi se non producesse piu` il 
driver linux.


 linux.
e poi c'era la marmotta che confezionava la cioccolata.......
Giustifica perche' nvidia ha da perdere dal rilasciare driver opensource.

 Giustifica perche' nvidia ha da perdere dal rilasciare driver opensource.
Cazzo ne so? Guarda, gli intransigenti devono uscire dalla porta e 
lasciare l'aula. Perche`? Semplice. La liberta` di ogni persona (fisica 
o no). Vuoi rilasciare il driver open? Fallo. Non vuoi farlo? 
Liberissimo.
Odio le costrizioni. Se i linuxari credono che sia liberta` imporre il 
modello opensource, sbagliano e di brutto. C'e` la parola IMPORRE che 
stona.


 stona.
e allora non imporre il tuo modello closed source.

 *TUO* dillo a qualcunaltro, io sviluppo solo open. Occhio con chi parli.
Chi sta imponendo qualcosa sei tu, non io. TU richiedi tutto open. Io 
do la liberta` di avere open e closed, a piacimento.


 la liberta` di avere open e closed, a piacimento.
no, io sto dicendo che io compro solo se e' open, ma non sono l'unico
acquirente.

 
Tu, ma perche` le compagnie devono fare quello che dice il dittatore? 
Ripeto, OpenAFS e` OPEN-SOURCE, OPEN!! Eppure...
PS. Sto notando che stanno sorgengo articoli sulla mia posizione, sulla 
mancanza di stabilita`. Puo` darsi che ci siamo svegliati? Ma linus 
ancora sta nel limbo, quindi credo sia fatica sprecata.


 ancora sta nel limbo, quindi credo sia fatica sprecata.
posta i link
ciao

 ciao
http://www.zdnet.com.au/news/software/soa/Why_Linux_isn_t_ready_for_desktops/0,2000061733,39202374,00.htm
http://akaimbatman.blogspot.com/2005/07/linux-desktop-distribution-of-future_07.html
Abbastanza 
noti come link, sia in osnews che slashdot.


 ha scritto nel messaggio 
news:2005072208172195335%senseiwa@tinit...

Perchè purtroppo i progettisti del kernel sono un pugno
di cialtroni. L'ho detto una volta, e lo ripeto. E mi dispiace,
perchè qualche programmatore di talento c'è anche, e
qualche riga di codice valida nel kernel di Linux c'è anche,
ma è la ottusità pazzesca della comunità Linux in generale
a determinare l'impossibilità di avere un kernel adatto
ad un uso desktop. Questi non solo sbagliano, ma si rifiutano
pervicacemente di rivedere le loro posizioni.
Riguardo al kernel di Linux, il primo sbaglio è stato quello di
creare un kernel monolitico. Se Linux avesse avuto alla base
un microkernel (a ring 0), con i servizi di sistema (a ring 1),
i sottosistemi (a ring 2), ed i processi (a ring 3), probabilmente
avrebbero ottenuto un sistema più difficile da sviluppare agli
inizi, ma i vantaggi in termini di eleganza e di pulizia del
codice sarebbero stati inimmaginabili.
E' chiaro che avrebbero perso la portabilità su piattaforme
diverse da x86, ma adesso avremmo un serio concorrente
a Windows.
Se i drivers fossero visti come servizi del sistema (e non come
moduli/pezzi di kernel), qualsiasi aggiornamento implicherebbe
semplicemente la sostituzione del binario che contiene quel
servizio. Non ci sarebbero problemi a mantenere la compatibilità
binaria, perchè gli indirizzi delle funzioni, delle procedure e delle
variabili verrebbero determinati a runtime dal sistema (il
kernel ed i servizi semplicemente manterrebbero una tabella con
gli entry point delle varie funzioni e con gli indirizzi delle variabili,
ed ogni volta che viene richiamata una funzione verrebbe calcolato
l'indirizzo corretto dal sistema in modo del tutto trasparente).
Purtroppo non è così. Ti aspetteresti poi che iniziassero a scrivere
qualche nuovo sistema concepito dalle fondamenta per
essere moderno e facile da usare. In fondo, sono quelli
maggiormente in vantaggio nello scrivere un sistema
di questo genere, perchè hanno il codice dei drivers Linux
che può essere portato nel nuovo os. Alla fine, si otterrebbe
un os gratuito, facile da usare e da mantenere, e che riconosce
tutto l'hardware che viene oggi riconosciuto da Linux.
Invece no, continuano a spingere sui loro vecchi errori (ABI
stable non sense), ed a mettere patch su patch per tenere in
piedi il loro carrozzone.
Saluti
Vegeta

 
La api stable non sense, e` la volpe e l'uva. Non riesco, desisto e 
dico che e` una merda.
PS. mi fa paura essere d'accordo con te... :)


 a Windows.
E questa non è una cosa da sottovalutare, secondo me.
Linux mi pare nacque con l'idea di essere facilmente portabile, e non a
caso una delle principali vanterie della Debian (sul sito) è l'essere
"il sistema operativo universale", essendo sostenuto per andare su 9-10
piattaforme.
Forse a te questo non importerà, a me si, invece e sono decisamente
contento di avere una Debian sul mio Mac e una sul mio PC.
E così molte altre persone...
-- 
L'importante, dico, l'importante
è non sbagliare mai CD
perchè un assolo di mandolino
può romperti i coglioni (Antonio Albanese)

 Forse a te questo non importerà, a me si,
a me pure, ma a Linus all'inizio non importava affatto, quindi non è che 
abbia scelto quella strada per renderlo portabile, anzi.

 abbia scelto quella strada per renderlo portabile, anzi.
Potrebbe essere che Stallman & C., una volta deciso di implementare
Linux nel progetto GNU, abbiano convinto Linus della cosa se lui
all'inizio non ne era convinto come dici.


 piedi il loro carrozzone.
a quando il vegeta os?

 andrebbero riscritte per portarlo da una piattaforma ad un'altra.
non se lo disegni esclusivamente per un tipo di processori. Se un
processore non ha 4 stati di funzionamento come la famiglia i386 il
discorso di vegeta e' morto.

 noti come link, sia in osnews che slashdot.
si', noto anche che le critiche mosse non sono pertinenti col dicorso fatto.

 piattaforme.
11, di fatto sarge amd64 e' stata rilasciata come stable, anche se in
ritanrdo dagli arti porting. In piu' ha un altro port non rilasciato stable.

 abbia scelto quella strada per renderlo portabile, anzi.
se e' per quello all'iinzio a linus interessava leggersi le news e non
aveva manco il multitasking. Pero' le cose si sono evolute rapidamente

 pensa la gente NORMALE.
Difendere i problemi seri di linux, e questo e` un gravissimo problema, 
risulta solo nella stagnazione della situazione.
Non a caso linux e` adottato solo da grandi aziende che possono 
permettersi sysadmin che lo mantengano e sui server. Non vedrai la dell 
che ti raccomanda linux. Nessuno si sogna di metterlo sul desktop.
Il perche` e` da ricercare, altrimenti, che cavolo e` stato sviluppato 
a fare? Per i server? Per gli smanettoni? Volpe e l'uva?


 discorso di vegeta e' morto.
Portare un microkernel e` estremamente piu` facile di un kernel 
monolitico. Meno cazzi cui guardare. Darwin e` un esempio banale.


 portabilita'.
Questo non significa che lo aveva scritto avendo in mente la 
portabilitą. Ripeto, se vai a leggere uno dei famosi primi messaggi dove 
Linus parlava del progetto che stava scrivendo, diceva chiaramente che i 
suoi interessi erano utilizzare tutte le possibili estensioni del 386, 
anche se questo significava scrivere un kernel non portabile su altre 
architetture.
Poi in parte corresse il tiro nel suo famoso flame con Tanenbaum dicendo 
che avendolo realizzato aderente agli standard POSIX di fatto linux era 
abbastanza portabile.

 fare, le licenze non sono compatibili.
Direi che questo è falso, altrimenti non mi spiego come mai permettano
l'esistenza di driver di lettura di file system differenti da quelli
utilizzati da windows, oppure di un driver bttv generico, oppure ancora
di un driver alternativo per i lettori cd in grado di permettere la
conversione automatica dei cd audio in wave (una cosa simile vi era
anche per linux ai tempi del 2.2)
Henryx


Vedi che non c'è bisogno di GalaxyOS per dimostrare
che sono cialtroni.
Hai presente quella famiglia di sistemi operativi
prodotta a Redmond? Si? Ti risulta forse che
cambino le API e l'ABI ogni 3 giorni perchè
"tanto si ricompila"?
Oppure hai presente FreeBSD?
Saluti
Vegeta

 fare? Per i server? Per gli smanettoni? Volpe e l'uva?
io ne conosco di gente normale che usa il computer con linux come
desktop. Probabilmente viviamo in due mondi distinti.

 anche per linux ai tempi del 2.2)
anche qua, driver o applicativo in userspace?

 monolitico. Meno cazzi cui guardare. Darwin e` un esempio banale.
mach per esempio, purtroppo, non lo e'. pistachio, altro esempio, e' un
microkernel non portabile.
Insomma, e' l'idea stereotipata dei microkernel. Un kernel fatto bene e'
portabile tranquillamente.

 abbastanza portabile.
ti ripeto: linux e' nato come programma per le news. Poi si e' evoluto.

 Oppure hai presente FreeBSD?
quianti moduli proprietari esistono per freebsd?

 ritanrdo dagli arti porting. In piu' ha un altro port non rilasciato stable.
Che spettacolo, guarda, se fra un anno quelli della Intel dovessero
mettere dei "regalini" di DRM nei loro processori, io mi faccio la Sparc
(che ormai pure la Apple è andata) e avrò sempre la mia Debianuccia :)
Sono soddisfazioni! (cit.)


 compresi nel kernel...
E ricorda: *non* tutto puo` essere nel kernel, perche` diventa una cosa 
immonda (gia` lo e`...). Troppe cose in mezzo che non c'entrano un 
cazzo: una webcam nel kernel??? Nel 97 sarebbero solo inorriditi al 
pensiero, ma ora, buttiamoci dentro tutto, ogni cosa fa brodo, se non 
funziona la fai funzionare (ma non curi il problema).
E` malato... GNU non si comporta cosi`. Linux si. Perche`?


 portabile tranquillamente.
Vero, ma io parlo di facilita`. I numeri non mentono. Se hai 10M di 
righe di codice e` piu` facile o meno di uno che ne ha 50K ??


 quianti moduli proprietari esistono per freebsd?
E che c'entra?
Saluti
Vegeta

 
Beh, preferisco parlare di un OS su cui mettere le mani. Di buoni 
progetti tanti ce ne stano... QNX? NeXT/OSX?



Non è un segreto che io ami QNX (si vede?).
L'unica cosa che ritengo perfettibile è il fatto che sia possibile
incrementare le prestazioni mettendo i servizi a ring 1. In tal
modo, i servizi possono scrivere direttamente nello spazio
di indirizzamento dei processi senza bisogno di usare
sistematicamente meccanismi a memoria condivisa.
Saluti
Vegeta

 funziona la fai funzionare (ma non curi il problema).
ti devo ricordare cosa non mette M$ in kernelspace? lo sai vero che non
c'e' solo il kernel?
Ciao

 righe di codice e` piu` facile o meno di uno che ne ha 50K ??
se sono 10 milioni di righe vuote :-)
penso che concorderemo che c'e' una parte di sistema operativo che
dipende dall'hardware e una che non lo e'. Prendiamo per esempio il
kernel di openbsd, tanto per cambiare in /sys/arch hai la parte
dipendente dall'hardware poi hai il resto del codice che e' condiviso.
Portare il bsd non vuol dire portare tutto, vuol dire portare quello che
c'e' in arch.
Ora, quando porti un s.o. microkernel porti la minima parte, guarda caso
la stessa cosa che c'e' in arch

 E che c'entra?
ma il problema non e' dell'abi per permettere lo sviluppo dei driver
proprietari?

 ...che tra l'altro non c'entrano nulla.
secondo me le reti invece si prestano bene a modellare i processi di
passaggio messaggi dei microkernel. Comunque il flammone finira' l'1
agosto, perche' parto per le ferie :-)

 kernelspace per permettere di inviare i file piu' verocemente ai client.
Questo tutti gli OS per server decenti: Il famoso e magico sendfile.
-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: 
http://vvolonghi.blogspot.com
http://weever.berlios.de

 Questo tutti gli OS per server decenti: Il famoso e magico sendfile.
questo cosa: l'avere server in kernelspace o avere la syscall sendfile?

 wrote:

Tu hai scritto che hanno un pezzo di IIS usato per mandare file piu`
velocemente. sendfile e` esattamente questo. Un pezzo di un qualsiasi
server web, messo li` per mandare file piu` velocemente.
Il fatto che tu lo consideri o meno una syscall poco importa, il punto
e` che c'e` qualcosa in kernelspace usato per mandare file ai client, se
e` usabile da tutti, oppure solo da IIS (oppure ce lo mette IIS) non
cambia nulla.


 server web, messo li` per mandare file piu` velocemente.
sendfile almeno su unix e' una syscall, non e' un programma. La copia
viene fatta tutta nel kernel, questo non implica che tutto il software
giri in kernelspace.
Se cerchi negli archivi di questo newsgroup dovresti trovare un vecchio
thread legato ad IIS, il webserver di redhat integrato nel kernel e il
discorso sulla syscall sendfile.

 proprietari?
Ed allora?
Saluti
Vegeta

 che gli pare.
Perche` cazzo hanno messo merda nel kernel quando dicevano che cio` era 
*male*? Perche` fanno i buffoni con le proprie affermazioni? Non 
eludere il discorso, e non portare ``ma ms fa questo e quello'', 
perche` si parla di linux e non di windows.


 la stessa cosa che c'e' in arch
Chiaro, un kernel *dovrebbe* avere una minima parte dipendente 
dall'architettura, MMU, CPU, Bus, e altre piccolezze.
C'e` da dire, che molte volte, in kernel monolitici, la gente mette 
parti in assembly embedded, cosa che viola tra l'altro lo standard iso 
c, ma vabbe`. Questo lo fa per prestazioni, che ne so, sfruttando SSE2 
o AltiVec, ma rende il codice poco portabile. Siccome in un microkernel 
certe cose non ci stanno... c'e` meno probabililta` di trovarle, ecco 
perche` e` piu` facile. Linux e` abbastanza portabile.


 
Non so. Per ora mi pare di ricordare siano a ring user, e non e` male. 
Metterli a ring 1? Mh... E` fattibile. Tra l'altro, devo vedere un 
attimo OSX su x86. Li vediamo veramente a che ring gira tutto in 
ambienti comparabili (sempre su intel).


 agosto, perche' parto per le ferie :-)
Si certo, Ottavio, ma non influisce l'ABI! ;)


 lì dentro ci sia un errore.
Vorrei far notare che questa *era* la filosofia unix...


 Ed allora?
e allora anche se freebsd ha l'abi stabile non gliene frega nulla a nessuno

 nel kernel... beh... la fata turchina mica interviene :)
in verita' quello che dici e' confutabile. Mi e' venuto in mente adesso.
pensa per esempio ai rootkit. E non solo, ci sono state delle beghe in
lkml per l'abuso di hook per tirarsi fuori simboli gpl anche se i driver
non lo sono.

 perche` e` piu` facile. Linux e` abbastanza portabile.
su sta cosa delle istruzioni simd nutro dei dubbi. Per esperienza le
istruzioni simd pagano quando si fanno grosse operazioni sui numeri tipo
filtraggi. Ma per le funzioni di un kernel questo caso e' uno scenario
poco probabile.


In realtà il programmatore non vede l'approccio a
pseudoregistri.
All'inizio di ogni programma C per GalaxyOS tu
ti trovi un bel
#include "galaxyos_baselib_v1"
che ti include una API ad oggetti che ti nasconde
completamente l'approccio a registri. Per te
esisterà una
Function GetVersionOS (Var Version: integer);
non ti interessa il fatto che essa internamente viene
implementata usando EAX=CazziMazzi.
L'approccio procedurale a registri, tuttavia, rende
molto più efficiente la comunicazione tra i
processi, permette al kernel di leggere lo stato
di un processo senza interpellarlo esplicitamente,
e soprattutto rende molto più semplice garantire
la retrocompatibilità del codice.
Facciamo un esempio classico per capire il
motivo.
Partiamo dal presupposto che la baselib di GxOS
è associata alla versione del kernel e dei servizi
di sistema.
Quando esce GxOS 2.0, ci sarà un nuovo kernel,
ed una nuova baselib.
Ora, supponiamo di avere scritto un'utility che legge
i settori sul disco, e supponiamo che questa utility
sia stata compilata per GxOs 1.0 con la baselib
vers. 1.0.
Ora, supponiamo che in GxOs 1.0 ci sia una funzione
chiamata ReadSector che legge il settore nr. x dal
disco nr. y.
Nell'approccio a registri la funzione corrisponde alla
StringFunction "DiskManager",
RegEAX=7266272 (ReadSector),
RegEBX=Nr.Disco
RegECX=Nr.Settore
 Nota che, poichè il numero di settore si mette in un
pseudoregistro a 64 bit, con questa funzione è possibile
indirizzare solo fino a 2^64 settori.
Dopo tre anni esce GalaxyOS 2.0, esiste una nuova
funzione per la lettura dei settori del disco. Si chiama
MuReadSector, e nell'approccio a registri corrisponde
a:
StringFunction "Disk Manager"
RegEAX=7266272 (MuReadSector)
RegMU1=Nr. settore (64 bit Hi)
RegMU2=Nr. settore (64 bit Lo)
RegMU10=Nr. disco
Notate che:
a) abbiamo cambiato il nome della funzione;
b) abbiamo cambiato completamente la sintassi. Ora
non si usano i pseudoregistri EAX,EBX... ma i
pseudoregistri MU, un set di 256 registri che
affiancano i pseudoregistri nel normale funzionamento
c) abbiamo esteso la funzione per indirizzare fino a
2^128 registri.
E' chiaro che il programmatore userà una baselib v2_0
in cui la funzione si chiama MuReadSector. Quindi,
il cambiamento di nome della funzione viene "avvertito"
dal programmatore per via della diversa libreria base
di sistema.
Ma un vecchio binario compilato per Gx1.0, potrà funzionare
su Gx2.0?
SI. Anche se abbiamo cambiato completamente
la sintassi della funzione.
Infatti, tutte le librerie base aggiungono (in modo trasparente
al programmatore), il numero di release della libreria nello
pseudoregistro VER. Quindi, il vecchio binario fa le sue
vecchie chiamate, ponendo però sempre un bel VER=1
nei suoi pseudoregistri.
Cosa succede quando il kernel 2.0 di GxOS si vede
eseguire una chiamata con VER=1? Semplice, richiama
una routine di traduzione che converte la vecchia sintassi
nella nuova (ossia, pone 0 in RegMU1, il contenuto di
RegECX in RegMU2, il contenuto di RegEBX in RegMU10,
e pone VER=2 nello pseudoregistro). Dopo, richiama
la corretta routine prevista dal kernel 2.0 con il nuovo
set di pseudoregistri.
Il programmatore non si accorge di niente. L'utente vede solo
che il vecchio programma, anche se disegnato per GxOS 1.0,
continua a funzionare anche sul 2.0.
Segue dunque, che finchè non vengono cambiati gli
identificativi numerici delle funzioni, possiamo cambiarne
il nome quante volte vogliamo (ne terremo conto per mezzo
della libreria base), e che possiamo anche mantenere la
compatibilità con vecchie chiamate per mezzo dello
pseudoregistro VER.
Saluti
Vegeta

 poco probabile.
Basta pensare ai driver per audio/video.
E comunque, impara ad astrarre, se uno fa un esempio, non vuol dire 
solo quello, forse e` un esempio come tanti...




Stiamo parlando di compatibilita` binaria riguardo l'uso di kernel 
extensions. Un modo o l'altro e` indifferente, basta rimanga quello. Se 
decidi di usare nomi, non li cambi, se usi registri non li cambi.
I nomi nei moduli dovrebbero essere standard ed  in parte lo sono.
Vegeta preferisce registri fissi? Va bene, basta siano stabili.


 
Io parlo dell'utilizzatore del kernel: colui che scrive i driver. Lui 
vede i cambiamenti eccome... E gli dai scompensi fisici e mentali a 
mettergli i registri di mezzo.
Le variabili nominative sempre.


 disinteresse dei produttori a fare software gpl.
Lo sai che questo equivale a dire che la colpa delle sparatorie č dovuta
al disinteresse dei produttori di armi, vero?
Henryx

 anche qua, driver o applicativo in userspace?
Driver. Una scheda con chipset BTTV dubito che venga utilizzata da un
applicativo in userspace se non vi è il driver
Henryx

On 2005-07-27 16:07:03 -0500, 
henryx.b...@libero.it
 (Enrico 
"Henryx" Bianchi) said:

Questa e` bellissima e me la segno! :D


 al disinteresse dei produttori di armi, vero?
Sara` l'ora tarda ma non ti seguo nella metafora.
Il discorso di Ottavio Campana e` molto semplice.
Se il problema fosse l'ABI stabile, perche` FreeBSD NON ha, al pari di
linux, i driver delle periferiche piu` esoteriche?
La domanda e` retorica.


 La domanda e` retorica.
Mica molto retorica. In linux non c'e` un driver che e` uno (*) scritto 
dai produttori. Stessa cosa per freebsd. Tutti sono scritti da persone 
che volevano far funzionare il proprio hw.
Non stiamo parlando della presenza di driver PUNTO, ma della presenza 
dei driver dei *produttori*, una crescita commerciale, non solo un 
giocattolo su cui far funzionare a calci device, cosa che per ora e` 
cosi`. Usare il driver nv di xorg/x11 e` da scemi quando si puo` usare 
quello nvidia.
(*) E` una iperbole, per chi cominciasse a tirar fuori i 3-4 nomi stranoti.


 il C di piu`.
Vero. Ma basta che tu scriva delle funzioni e procedure
che te li gestiscano una volta per sempre, che non hai
più bisogno di ricordarti come i registri vengono
assegnati.
Saluti
Vegeta

 pseudoregistro VER.
sbaglio o questo mi ricorda molto come funzionano le syscall in linux?

 Basta pensare ai driver per audio/video.
dove fai I/O in dma, non fai signal processing.
Io cerco anche di astrarre, ma non c'e nulla da astrarre in molti casi

 reiserfs, e cosě via
e allora? non stai confutando la mia idea, anzi, sembri darmi ragione.

 Ma Linux non lo fornisce.
questo e' falso. tu puoi aggiornare le libc senza dover aggiornare il
sistema. Basta che fai un aggiornamento per vederlo.
come diavolo fai a sostenere delle falsita' simili?

 vuol dire che forse e` sbagliato, meglio buttarlo e riprogettarlo.
pero' restare sempre con la stessa interfaccia non e' sempre un bene.
Dopotutto quando linux e' nato non c'erano molti hardware che oggi sono
di uso comune, citiamo per esempio usb. Mi sembra un peccato di
presunzione dire che la prima interfaccia stabile debba essere quella
definitiva.

 al disinteresse dei produttori di armi, vero?
no. la tua mi sembra una *tanto* libera interpretazione.

 Mica molto retorica. In linux non c'e` un driver che e` uno (*) scritto dai produttori
coff coff! intel?
http://ipw2100.sourceforge.net/
http://ipw2200.sourceforge.net/
Per freebsd non ci sono.
La tua iperbole serve a poco. E' lapalissianamente falsa e stai cercando
di arrampicarti sugli specchi per difendere una posizione
intrinsicamente errata.

 definitiva.
Non e` presunzione, e` design. E` intelligenza. E` ancora piu` 
intelligenza affiancare API nuove migliori se quella vecchia non e` 
superlativa, mantenendo la compatibilita`.
La stupidita` grossa e` stata usare la sincronia. Mai l'avrei accettato 
io un stack sincrono, le prestazioni sono ridicole, ma linus ha 
approvato perche` un milione di cose fatte male e` meglio che nulla. 
Non e` vero.
La gente deve pensare prima di usare la tastiera, cosa che raramente fa 
su linux. Purtroppo. E gli effetti si vedono (IDE per esempio).


 intrinsicamente errata.
Ho *espressamente* detto di non prendere quei famosi 4 gatti noti.
Poi: vuoi dire che sbaglio?
Facciamo il conto dei driver dei produttori su linux e su windows? Dai, 
sii serio. Non dimostri nulla tirando fuori 5 nomi, anche 10.
Linux non ha e non avra` supporto commerciale manco se piangono in 
aramaico con accento siriano, almeno fino a quando sara` sviluppato 
come un gioco.


 ha scritto nel messaggio 
news:dc9rr8$k4p$1...@ftp.dei.unipd.it...

In realtà purtroppo non è vero.
http://server1.belchfire.net/protected-cgi-bin/manServer_107.pl/usr/share/man/man2/syscalls.2
Ma non è tanto quello il problema. Qui io parlavo di binario
non intendendo processo utente (ring 3), ma parlavo di
binario intendendo il driver (servizio per GxOS a ring 1 o
modulo per Linux a ring 0). Qui sono mazzate
perchè i moduli sotto linux non sono compatibili a
livello binario perchè manca l'ABI standard.
Sotto GxOS un driver progettato per la versione 1.0 del
sistema dovrebbe funzionare anche su GxOS vers. 2.0.
Magari il driver sarà deprecato, magari funzionerà a
bassa velocità per via dell'overhead delle routine di
traduzione, ma dovrebbe funzionare.
Sotto Linux questo non è possibile farlo.
Saluti
Vegeta

 
Overhead. Vorresti usare un preprocessore sul codice? Inutile. Vivi nel 
secolo attuale e leva l'assembly dalla mente, e` scomodo.


 sbaglio o questo mi ricorda molto come funzionano le syscall in linux?
Le syscall non hanno alcun pseudoregistro VER. Quindi, se
cambi la sintassi delle syscall, sei costretto a cambiare il codice.
Saluti
Vegeta

 esattamente lo stesso.
AAAGGGHHHRRRR!!! Questa e` eresia! Pentiti finche` sei in tempo, trova 
il signore prima che il signore trovi te!
Spero tu scherzi:
uns`accod'iaccent^i(grveur* periferique, ordineteurStructurelle* nonSo)
nomelunghendiunaKosaBelissimeninlincuaTeteska()
Cosi` si che uniformiamo i programmi! Proprio standard! Col cazzo che 
qualcuno leggera` i programmi sviluppati in tibet...


 ha scritto nel messaggio 
news:2005072815003633169%senseiwa@tinit...

Infatti č una provocazione, che ho scritto semplicemente
per fare capire che una volta che le syscall vengono
identificate internamente al kernel con degli identificatori
numerici, non ti importa quali sono i name services
che vengono assegnati dalla libreria.
E poi, in fondo, se usi codice closed source a te puň
andare benissimo. Il codice del tuo driver č in italiano,
tanto tu distribuisci il binario.... Stallman non puň
capire quello che c'č scritto? E chi se ne frega, tanto
il tuo driver č closed.... :)))))))
Ciao
Vegeta

 no. la tua mi sembra una *tanto* libera interpretazione.
Dici? Secondo me calza a pennello.
Ottavio, il problema non è che noi vogliamo a tutti i costi darti torto
o che tu sei in malafede, il problema è che tu (e con te molti altri)
vedi le cose da fondamentalista, indipendentemente dal fatto che tu ne
sia consapevole o meno
Henryx

 e allora? non stai confutando la mia idea, anzi, sembri darmi ragione.
Sigh, ok, fai come se non avessi mai nominato alcun driver per file
system. Del driver BTTV generico, invece, cosa mi dici?
Henryx

 linux, i driver delle periferiche piu` esoteriche?
Perché FreeBSD, sostanzialmente, rispetto a linux non viene considerato
da nessuno
Henryx

 sii serio. Non dimostri nulla tirando fuori 5 nomi, anche 10.
no, non parlare di windows. Ti lamenti che io voglio cabiare il
discorso, non farlo nemmeno tu, altrimenti rpediche bene e razzoli male.
Il discorso e': volgiamo confrontare i driver dei produttori di linux
che non ha l'abi stabile e freebsd che che l'ha.
lascia stare windows. L'abi stabile non e' garanzia di niente.

 loro scelte (commerciali o non), perché devono essere incolpati?
io non li incolpo. Il discorso e' nato dal fatto che se non rilasciano
almeno le specifiche, io non compro.

 su linux. Purtroppo. E gli effetti si vedono (IDE per esempio).
eh!?!? cazzarola, questo e' fare di ogni erba un fascio. Dire che l'abi
del kernel implica brutti ide e' una cazzata non pertinente. Vuoi
parlare di kernel? allora non passare in userspace.

>> dovuta al disinteresse dei produttori di armi, vero?
l'ultima cosa che hai detto mi sembra piu' sensata della storia dei
produttori di hardware

 system. Del driver BTTV generico, invece, cosa mi dici?
ne esiste uno gpl per windows?

 qualcuno leggera` i programmi sviluppati in tibet...
mi vengono in mente i francesi..... con la loro mania di tradurre tutto
in francese....

 cambi la sintassi delle syscall, sei costretto a cambiare il codice.
ti droghi? lo sai che le syscall sono standardizzate? Non e' che
torvalds si inventi i parametri.....


cd /pub
more beer

 lascia stare windows. L'abi stabile non e' garanzia di niente.
E` garanzia che il lavoro di Matrox non venga buttato al cesso.
E` quello che le case produttrici pretendono.
E` quello che la gente normale si aspetta, non buttando al cesso i 
driver ad ogni update.
E` quello che linux deve avere se non vuole rimanere un giocattolo.


 ...).
veramente la configurazione dell'aspeto in kde è fatta veramente bene:
puoi scegliere di usare un tema già pronto che configura tutto, oppure
cambiare il singolo parametro del tema (colori oppure window
decorations ecc..), oppure configurare ogni cosa come si vuole
l'utente non è oberato di 500 scelte come dici, e nonostante tutto ha la
possibilità di configurare tutto come vuole
ciao
-- 
boydon

 ciao
Permettimi di dirti che window decoration, style & co devono essere la 
stessa cosa. I temi non ci sono ad esempio. Ogni pre-setting dovrebbe 
essere un tema e solo li dentro modificare le scelte, non all'esterno 
di un tema! Scelgo plastik e me lo modifico, mica vado prima in style, 
plastik, poi mi muovo in window decor e scelgo kde1, poi in colors e 
scelgo cde, poi mi muovo in font... Meglio andare in themes, scegliere 
plastik, se non piace, si modifica pezzo pezzo. E` piu` coerente.
C'e` un po' di lavoro da fare ancora. Qui di meno, sotto alla base 
moooolto di piu`.


 di acqua di fonte.
tu sai come fanno gli altri? sai se e' fattibile in altro modo? Io non
lo so e non mi pronuncio.


e' interessante notare come non assicuri che non ci siano bachi. Che non
assicuri una maggiore sicurezza. Che non assicuri un aiuto dalla
comunita per l'aggiornamento dei driver. E' interessanto come sorvoli
che altri sistemi operativi opensource che hanno una abi stabile non
abbiano driver closed source.
Insomma, 4 frasi inutili.

 Insomma, 4 frasi inutili.
Perche` dire che avere i sorgenti e` garanzia di esenza dei bug e` pura 
idiozia e lo sai bene.
Semplicemente, e` garanzia di vedere quello che fa. Opensource non vuol 
dire perfetto, ricordalo.
Poi, sto parlando di sviluppo in futuro, di liberta` per tutti. Non e` 
liberta` costringere gli altri. Oppure vogliamo usare un dizionario?


 
Si, non mettono i driver. Non accettano solo per averlo nell'elenco un 
pezzo di sw scritto con i piedi e non progettato con gli altri.


 plastik, se non piace, si modifica pezzo pezzo. E` piu` coerente.
sensei, aggiornati, se non mi credi ti posto uno screnshoot
 
ciao
-- 
boydon

 tanto cazzata piu' cazzata meno....
giusto per dire, eh, non c'entra molto con il discorso, ma se non 
ricordo male in VBA su Excel italiano (sto parlando della versione 
Office 97) nelle macro era riportato ad es. "Foglio1.B1", mentre su 
quello in inglese "Sheet1.B1". Morale: le macro fatte su excel in 
inglese non erano compatibili (ergo: non funzionavano quando andavi ad 
eseguirle) su Excel in Italiano e viceversa. Spero che ad oggi non sia 
ancora cosě, ma all'epoca era cosě, l'ho visto con i miei occhi, 
purtroppo. Direi che non ci sono andati molto lontani da una idea cosě 
malsana :D

 torvalds si inventi i parametri.....
E se un giorno fosse costretto a cambiare quelle sintassi?
Saluti
Vegeta

 malsana :D
a me pare di ricordare che il vba permettesse anche la sintassi tipo
  Se a > b
   ..
  FineSe
ma probabilmente deliro

 ne esiste uno gpl per windows?
Da quanto ne so, si (i sorgenti dei driver originali di tale chipset
furono rilasciati liberamente, o almeno è questo ciò che mi fu detto)
Henryx

 almeno le specifiche, io non compro.
Guarda che questo è differente da quello che dicevi prima. Inoltre,
anche il non rilascio di specifiche è una precisa scelta che deve essere
(nel bene  nel male) accettata. Apple, ad esempio, durante il rilascio
di MacOS Classic scelse di non rilasciare liberamente le specifiche per
la scrittura dei driver per il suo sistema operativo
Henryx

 pezzo di sw scritto con i piedi e non progettato con gli altri.
apprezzo la tecnicita' del commento

 Guarda che questo è differente da quello che dicevi prima.
in verita' era quello che era stato scritto all'inizio del thread.
la cosa mostruosa che sensei sostiene e' l'apologia del closed source
per la liberta' dell'utente, per le performance e per la stabilita'.....

 idiozia e lo sai bene.
mentre non averli rende sicuramente piu' difficile il debug e lo sai bene.

 furono rilasciati liberamente, o almeno č questo ciň che mi fu detto)
quando torno dalle ferie cerco su google.

 E se un giorno fosse costretto a cambiare quelle sintassi?
non succede. Si chiamano standard. Se ne creano delle nuove.

 malsana :D
In Office 2000 (sono arrivato fin lì) è ancora così, tra l'altro con
una complicazione aggiuntiva. Se tu prendi un foglio fatto in inglese con
delle formule in inglese (neanche vere macro) e lo carichi con Excel in
italiano le formule funzionano. Ma se a quel punto ne aggiungi una in
inglese quella nuova non funziona (le vecchie sì!) e devi scriverla in
italiano (es. LUNGHEZZA invece che LEN, EXACT invece che IDENTICO). 
E sì, cambiano anche i nomi dei fogli a meno che tu non indichi
direttamente con un numerico (1,2,3) invece che con la stringa (questo
però l'ho visto non su VB che non uso e spero non userò mai ma in Python
con le estensioni COM).
Francamente vorrei conoscere quello che ha avuto un'idea del genere.
(probabilmente lo stesso che ha fatto cambiare i comandi di Word a seconda
della lingua e, se ben ricordo, addirittura alcuni switch dei comandi da
CLI in Windows 95, sull'ultima però potrei sbagliarmi...)
See you,

	Silver Drake

-- 

http://www.silverdrakenet.it


Australian Largest Bed, coverband extraordinaire

http://www.silverdrakenet.it/platy/carpe.html



 il tuo driver è closed.... :)))))))
Poi un bel giorno un'azienda prende programmatori di nazionalità diversa
per sviluppare un programma, sia pure closed, per questo sistema... Vorrei
vedere la scena, peccato che non esisterà mai...



Questa è grande...
Ma scusa, Mustek scrive un driver closed in
tibetano. Sarà un problema di Mustek? Sarà
una scelta di Mustek? Cosa c'entra il sistema
operativo?
Vuol dire che se prendono programmatori di
nazionalità diversa ed hanno i sorgenti in tibetano
vanno a menare il precedente team manager
che ha deciso di usare la baselib in tibetano
all'inizio del progetto.
Oppure, anche se sanno che possono usare
differenti baselib, in pratica usano sempre la
baselib in inglese e tanti saluti.
Avere una possibilità di scelta non significa
essere costretti ad usarla.
Saluti
Vegeta

 essere costretti ad usarla.
pero' puo' portare a piu' casino. come se non ce ne fosse abbastanza

 usarla.
Quindi hai inserito una funzione che non ha alcuna utilità e *al massimo*
serve a creare casino. Geniale...


 non succede. Si chiamano standard. Se ne creano delle nuove.
Succede. Basti che cerchi le syscall "obsolete" o
"unimplemented"
Saluti
Vegeta
.



Il debug lo fa chi fa il software. Non certo io che scrivo un altro sw.


 
Sorvolano con un aereo i paesi. Il francese dice ``siamo in francia, ho 
toccato la tour eiffel con un dito!'' .... :D
Scusa ma hai fatto il trittico delle barzellette!


 apprezzo la tecnicita' del commento
Non c'e` tecnicita`... leggi come fanno, quello che fanno.
Sono fanatici.
Il fanatismo FA MALE. Linux non e` cresciuto quanto avrebbe dovuto e 
potuto. Nessuno fa driver per linux proprio per fanatismo GPL-ista, 
senza API e ABI perche` cosi` e` per saecula saeculorum.
Dio mio, e` cosi` difficile non voler dogmi di fede per te?


  ciao
Per tua norma, credo fino al ragionevole dubbio, quindi se dici che in 
kde 3.5 e` cosi` ok, e` cosi`.
KDE 3.4 non era cosi`. Ci sono 3 temi, e le configurazioni le puoi fare 
all'esterno dei temi. Mentre volevo per almeno kde 3.4 i temi plastik, 
cde, cazzincul, maialosetoloso, sbabbari, ...
Forse e` un progetto per kde 4? Sono uscite le qt 4, forse e` in 
partenza un altro progettino...


 Scusa ma hai fatto il trittico delle barzellette!
L'ho fatto apposta, mi sembrava appropriato visto che si parla di GalaxyOS
:D


 all'esterno dei temi.
Sensei, ti posso assicurare che la gestione dei temi centralizzata c'č
da KDE 3.3
Henryx

On 2005-08-05 12:21:01 +0200, 
henryx.b...@libero.it
 (Enrico 
"Henryx" Bianchi) said:

Aspe`, KDE ha il menu themes da sempre. Che questo in realta` non sia 
utilizzato bene allora e` ancora cosi`.
C'e` un menu Window Decoration al di fuori dei temi? E Style (i 
controlli, bottoni...)? I colori? Se si, e` un errore, non dovrebbero 
essere fuori dai temi. Plastik e` un tema, ma alla 3.3 3.4 e precedenti 
non c'era un tema plastik, ma era tutto sparso.


 utilizzato bene allora e` ancora cosi`.
ho idea che non ci capiamo
una volta c'erano i vari menu per settare le varie parti (icone, window
decoration, style ecc..) e basta
dal 3.3 oltre a queste ce n'è una nuova che permette di settare tutto
con un unico tema.
quelle vecchie sono comunque rimaste, in modo che posso caricare un tema
completo e poi andare a cambiare un singolo aspetto
 
ciao
-- 
boydon