[C] Programmare un Sistema Operativo

[Mendocino89]

Originariamente inviato da Z80Fan

Molto bene.
Cmq i tuoi binari funzionano benissimo, ora devo solo riconfigurarlo, grazie mille!

Ringrazia debian !
Il problema con i binutils è abbastanza diffuso, è un bug....

EDIT: funge sia su Debian che su Mandriva.

[cdimauro]

Originariamente inviato da mindwings

@cdimauro
Un giorno forse, un giorno dirai del bene del software libero, senza portare alla ribalta sempre gli aspetti che tu consideri negativi.

Guarda che io contribuisco pure al software open source (non necessariamente "libero"; mi scuso se ho pasticciato coi termini prima, ma spero che il concetto fosse chiaro).

Semplicemente mi danno fastidio il fanatismo, la chiusura mentale e lo spreco di risorse che vi gravita attorno.

Rendiamoci conto che molti dei progetti che a te non stanno a cuore sono portati avanti e sviluppati su base volontaria.

Questo non giustifica gli errori di cui sopra.

Io utilizzo i driver proprietari Ati ma non biasimo il lavoro svolto da chi sviluppa driver completamente open, per il semplice motivo che mi forniscono un alternativa qualora ne avessi la necessita'.

OK, anche se non mi viene in mente nessun caso per cui si potrebbero usare.

Non sottovalutare l'opensource che si rivela un'ottima palestra per imparare tantissime cose, tra cui perche' no lo sviluppo di driver.

Bisogna anche vedere con quali progetti "si fa palestra".

Esempio: ti piacciono i compilatori, vuoi vedere e imparare come funzionano, ti rivolgi a GCC & co. "perché posso guardare i sorgenti", e dopo giorni di sbattimenti capisci che è meglio prendere un bel libro sull'argomento e sperimentare per i fatti tuoi...

Anche Z80Fan si sta divertendo a scrivere ed imparare molte cose sui Sistemi opertivi( dove per imparare l'unico modo efficace e' sporcarsi le mani... ) anche lui sta buttando tempo e risorse ?

Mi sono già espresso sull'argomento. Lo ritengo uno spreco nella misura in cui si rifanno le stesse cose.

Un altro clone di Linux per me rimane tempo perso, tranne per imparare appunto.

Discorso diverso se finalmente si comincia a sperimentare su cose nuove, come dicevo un po' di messaggi fa, ma è difficile perché la mentalità che circola nell'ambiente è che i s.o. devono necessariamente derivare da Unix (o Posix, in generale).

Se ti da' fastidio il fanatismo, non fomentarlo.

Certo che mi dà fastidio, e lo farei sparire. Di certo non aiuta calare la testa e far finta di niente.

Originariamente inviato da Z80Fan

Ho tralasciato intenzionalmente i vari messaggi sulla libertà di Linux, cmq lascio un ultimo appunto sul commento di cdimauro per chiudere il semi-OT (anche perchè di sistemi operativi stiamo parlando e quindi non è un OT totale):
La qualità dei driver nVidia per linux è molto alta (parlo da possessore di GTX275), ed anche io abolisco il fanatismo di libertà alla Stallman ( e i vari aneddoti su di lui ); cmq imho avere driver *molto* liberi (si possono anche tenere l'ultimissimo strato di accesso all'hardware) può aiutare sia noi che loro: se un driver è open source, può essere modificato per integrarsi meglio con eventuali grosse modifiche del kernel in tempi più brevi di quanto non possa fare nVidia (visto anche che ogni distro ha modifiche personalizzate) (esempio: certe volte mi si blocca temporaneamente il video, e lo schermo và come fuori sincronia, riesco a sbloccarlo solo andando in un terminale virtuale e poi ritornando, e a quel punto ho lo le finestre che erano aperte "sporche" come se le texture fossero state corrotte), e poi nVidia potrebbe avere una elevata quantità di persone che possono fare da beta-tester e debuggers praticamente gratis, che magari gli risolvono anche qualche bug su Windows se il codice in mezzo è uguale.
fine semi-OT

Il problema, come già detto prima, è che le GPU moderne sono mostri estremamente complessi. Le persone più titolate a realizzare driver sono gli ingegneri di nVidia, e questo anche a fronte di consistenti modifiche del kernel. Idem per il debug.

Di questo te ne accorgerai tu stesso quando dovrai realizzare di driver per il tuo s.o.. Per quanto detto finora, l'ideale dovrebbe essere rappresentato da una GPU di cui si abbia a disposizione tutta la documentazione necessaria.

Qui l'esempio di AMD/Ati è piuttosto eloquente: pur avendo rilasciato tutto ciò già da parecchio tempo, mettendo a disposizione alcuni suoi dipendenti e altri di Novell, la qualità dei driver open source per le Radeon è ancora anni luce indietro rispetto a quelli closed. E chissà come sarebbero ridotti senza l'aiuto fornito, appunto.

Nella vita bisogna imparare a essere meno idealisti e più pragmatici.

Cmq mentre ero via ho pensato a chiamare il kernel e il successivo os in 2 modi diversi, per il kernel ho pensato Brick, che in inglese significa "Mattone" e può riferirsi alla modularità del sistema, formato da tanti "mattoncini" quali sono i moduli, e magari si riesce a trovarci anche un bel acronimo

Occhio che "mattone" può anche avere un'accezione negativa.

Originariamente inviato da khelidan1980

No mi spiace ma questo problema è imho imputabile solamente al metodo di sviluppo del kernel, se ci fossero api/abi stabili non ci sarebbero problemi di adattamento, o quantomeno non sarebbe un caos come lo è ora

Questo è un altro grosso problema. Grazie di averlo ricordato.

Originariamente inviato da Z80Fan

Ok, cmq la seconda parte (riferita al debug) è ancora valida.

Per me no, perché ci vuole gente qualificata per farlo.

Vero. Forse una delle cause perchè ci sono poche case che creano i driver per Linux.

Mi sembra anche normale. Immagina un produttore che debba tenere conto di tutto ciò: dovrebbe impiegare non poche risorse per realizzare driver di qualità, e per un s.o. avente avente meno dell'1% del mercato non è certo conveniente.

[Rikiji]

Come procede? E' un po' che non passo di qui

[fero86]

quotone da parte mia per cdimauro

in particolare su questo:

Originariamente inviato da cdimauro

Un altro clone di Linux per me rimane tempo perso, tranne per imparare appunto.

Discorso diverso se finalmente si comincia a sperimentare su cose nuove, come dicevo un po' di messaggi fa, ma è difficile perché la mentalità che circola nell'ambiente è che i s.o. devono necessariamente derivare da Unix (o Posix, in generale).

sono d'accordissimo, é una cosa che fa alquanto incazzare anche me (sfogo represso risalente ai tempi in cui diedi sistemi operativi 1 e laboratorio). non si capisce perché poi debba esserci questa maledetta inerzia tecnologica. perché non guardare al futuro, agli ambienti managed che lavorano in modalitá supervisor (o "ring 0" o "kernel mode" che dir si voglia) ?
Microsoft sta facendo ricerca con Singularity e una prossima versione di Windows potrebbe essere interamente managed, perché non avviare un progetto GPL del genere? Singularity é open source ma non credo che sia propriamente FOSS secondo la definizione GNU.

[cdimauro]

Le "definizioni" di GNU, FSF & compagnia bella le lascerei perdere, visto che hanno ridefinito perfino il concetto di libertà (sei "libero" solo nella misura in cui sei costretto a fornire i sorgenti delle modifiche che hai fatto a un progetto GPL ).

Singularity è interessante, come pure il prossimo kernel "minimale" a cui sta lavorando Russinovich.

P.S. All'esame di sistemi operativi (credo fosse il '97, se non ricordo male) ho portato una tesina su AmigaOS.

[DanieleC88]

Originariamente inviato da fero86

Singularity é open source ma non credo che sia propriamente FOSS secondo la definizione GNU.

Non sto intervenendo negli ultimi post perché già in passato con utenti come cdimauro ho scambiato le mie opinioni riguardanti il software libero e ciò che vi gravita intorno. Però negli ultimi interventi vedo che state facendo un bel minestrone misto di open source/free software, cose che sono a volte complementari, ma non per questo necessariamente coincidenti.

Un software è "open source" secondo la definizione dell'OSI se rispetta questi punti: http://www.opensource.org/docs/osd

Un software è invece "libero" secondo la definizione della FSF se rispetta questi punti: http://www.gnu.org/philosophy/free-sw.html

È facile vedere che la relazione che collega i due insiemi non gode di proprietà transitiva.

Detto questo, Singularity è open source. La sua licenza (http://singularity.codeplex.com/license) sembra rispettare i punti stabiliti dall'OSI - mi mette solo un po' in dubbio il punto due: «2. That if any of the Software is in binary format, you will not attempt to modify such portions of the Software, or to reverse engineer or decompile them [...]». Non è però software libero, e nessuno gli chiede di esserlo.

E continuo a non capire le critiche alla natura "virale" della GPL: se non vi piace, basta non usarla.

[M4rk191]

Originariamente inviato da cdimauro

Discorso diverso se finalmente si comincia a sperimentare su cose nuove, come dicevo un po' di messaggi fa, ma è difficile perché la mentalità che circola nell'ambiente è che i s.o. devono necessariamente derivare da Unix (o Posix, in generale).

Io credo invece, che scrivere un OS senza partire da una base, sarebbe ancora più inutile, per due motivi:

1-Senza una base da cui partire, sarebbe difficile portare avanti un progetto, soprattutto considerando quanto è stato necessario per realizzare i moderni cloni open source di UNIX.

2-Linux che in ambiente desktop credo sia il clone UNIX più conosciuto, è (in confronto ad altri OS) poco diffuso. Un OS completamente nuovo, sarebbe difficile da pubblicizzare, mentre un fork di Linux o un "clone from scratch" avrebbe un impatto diverso. Quello che intendo dire è che se Linux fatica a diffondersi, che speranze può avere un OS di nuova concezione?
L'OS di Z80Fan viene scritto per fini didattici e non per conquistare il mercato, ma anche in questo caso, credo che risulterebbe difficile scrivere un OS da zero, senza averne un altro di riferimento.


Tornando completamente IT, il titolo del thread è "Programmare un SO" quindi presumo che oltre al kernel verranno in seguito scritti editor di testo, debugger e altre applicazioni di uso comune, giusto?

[khelidan1980]

Originariamente inviato da M4rk191

Io credo invece, che scrivere un OS senza partire da una base, sarebbe ancora più inutile, per due motivi:

1-Senza una base da cui partire, sarebbe difficile portare avanti un progetto, soprattutto considerando quanto è stato necessario per realizzare i moderni cloni open source di UNIX.

2-Linux che in ambiente desktop credo sia il clone UNIX più conosciuto, è (in confronto ad altri OS) poco diffuso. Un OS completamente nuovo, sarebbe difficile da pubblicizzare, mentre un fork di Linux o un "clone from scratch" avrebbe un impatto diverso. Quello che intendo dire è che se Linux fatica a diffondersi, che speranze può avere un OS di nuova concezione?
L'OS di Z80Fan viene scritto per fini didattici e non per conquistare il mercato, ma anche in questo caso, credo che risulterebbe difficile scrivere un OS da zero, senza averne un altro di riferimento.


Tornando completamente IT, il titolo del thread è "Programmare un SO" quindi presumo che oltre al kernel verranno in seguito scritti editor di testo, debugger e altre applicazioni di uso comune, giusto?

se uno inzia a scrivere un so pensando alla diffusione di mercato meglio che lascia stare,mentre l'innovazione potrebbe essere la chiave giusta per imporsi, e sarebbe molto ma molto più stimolante lo sviluppo

[Z80Fan]

Originariamente inviato da cdimauro

Mi sono già espresso sull'argomento. Lo ritengo uno spreco nella misura in cui si rifanno le stesse cose.
Un altro clone di Linux per me rimane tempo perso, tranne per imparare appunto.

Chiariamo: il progetto non vuole essere un kernel compatibile a livello binario con Linux, anzi, di Linux non c'è proprio niente, dato che non mi baso sui suoi sorgenti e non ho letto niente su come lavora internamente. Ho solo un'idea di massima su come è fatto (ad esempio che algoritmi usa, di schedulazione ecc...), quindi quello che verrà fuori sarà solo esternamente *simile* a Linux, giusto per facilitare eventuali porting di programmi e per riusare la eventuale conoscenza che qualcuno ha su Linux. Poi se metterò delle cose tipiche di Linux, sarà perchè mi ci trovo bene con loro.

Discorso diverso se finalmente si comincia a sperimentare su cose nuove, come dicevo un po' di messaggi fa, ma è difficile perché la mentalità che circola nell'ambiente è che i s.o. devono necessariamente derivare da Unix (o Posix, in generale).

Originariamente inviato da M4rk191

1-Senza una base da cui partire, sarebbe difficile portare avanti un progetto, soprattutto considerando quanto è stato necessario per realizzare i moderni cloni open source di UNIX.

Come dice M4rk191, uno completamente a secco di esperienza di sistemi operativi non può pretendere di innovare da subito, e poi i sistemi Unix-like hanno molta documentazione e moltissimo software disponibile, questo può facilitare successivamente quando dallo sviluppo del kernel passeremo al sistema operativo (magari riusciamo a portare la shell bash, prima di scrivere la nostra innovativa versione)

Occhio che "mattone" può anche avere un'accezione negativa.

Ouch!

Originariamente inviato da Rikiji

Come procede? E' un po' che non passo di qui

Abbastanza bene, spero che tu abbia dato un'occhiata ai nuovi sorgenti
Ora stò lavorando per interfacciarmi con il grub patchato che mi inizializza direttamente la modalità vesa, ma sembra che ho problemi di comunicazione (mi dice che la mem. video inizia a 0!)
Dovrò anche provvedere a un server svn su sourceforge sennò Zulutown mi spara

Originariamente inviato da M4rk191

Tornando completamente IT, il titolo del thread è "Programmare un SO" quindi presumo che oltre al kernel verranno in seguito scritti editor di testo, debugger e altre applicazioni di uso comune, giusto?

Si, toccherà fare anche quelle, a meno che non riusciamo a usare alcune già pronte. Cmq l'interfaccia grafica la faremo noi diversamente dal X server, quindi non tutto funzionerà subito (a meno che non provvediamo a una libreria che simula le chiamate X sul nostro manager)

Cmq ora finiamo l'OT sulla libertà di Linux ok?

[M4rk191]

Originariamente inviato da Z80Fan

Cmq l'interfaccia grafica la faremo noi diversamente dal X server, quindi non tutto funzionerà subito (a meno che non provvediamo a una libreria che simula le chiamate X sul nostro manager)

Leggendo su Wikipedia, cercando di capire di cosa si trattasse di preciso, ho letto che X è un gestore grafico per sistemi UNIX che non gestisce l'aspetto grafico, ma solo l'integrazione tra utente e server video. Mi chiedo, se sia assolutamente necessario un gestore grafico e se sia necessario distinguere il window manager dal gestore grafico. Inoltre OSX utilizza Quartz e X, SO *NIX usano esclusivamente X, mentre Windows cosa utilizza?

[Z80Fan]

Originariamente inviato da M4rk191

Leggendo su Wikipedia, cercando di capire di cosa si trattasse di preciso, ho letto che X è un gestore grafico per sistemi UNIX che non gestisce l'aspetto grafico, ma solo l'integrazione tra utente e server video. Mi chiedo, se sia assolutamente necessario un gestore grafico e se sia necessario distinguere il window manager dal gestore grafico. Inoltre OSX utilizza Quartz e X, SO *NIX usano esclusivamente X, mentre Windows cosa utilizza?

Beh, è utile, perchè ti permette di far comunicare la applicazioni con un server unico indipendentemente da come verrà visualizzato. Per esempio, ci può essere compiz sopra, che allora fornisce l'accelerazione 3d e gli effetti grafici, o come detto Quartz. Gli so *nix non usano solo X, X è sotto e sopra c'è il desktop manager (gnome e kde + famosi) e poi ancora il windows manager (motif, metacity, compiz, quello proprio di kde...).
Windows usa un sistema centralizzato, che fà sia da "server X" che da desktop e window manager. Funziona benissimo anche questo modo, inizialmente X era stato sviluppato quando ancora si usavano i terminali stupidi per accedere ad un sistema remoto, quindi X si basa sulle connessioni di rete per inviare i messaggi alle applicazioni (oggi non più perchè il server bypassa il sistema di rete per non intasarlo). Diciamo che un sistema centralizzato è anche più veloce, poichè non ha diversi strati a cui passare le stesse informazioni, e si può creare una cosa simile alla connessione a distanza con qualche trick. L'unico problema su Windows è che lo fanno girare in kernel mode, per questo si possono bloccare _tutte_ le finestre quando una è in mona (e a me non sò perchè mi succede spesso in windows ).
Quindi io per il nostro os penserei a una cosa simile ad entrambi: un server sotto che gestisce solo la comunicazione di eventi e cose del genere, ed un'altra chè avrà un collegamento diretto con quest'ultima per disegnare effettivamente le cose sullo schermo. Le applicazioni comunicheranno solo con il server. Per il momento non ci interessa avere la connessione a distanza, ma si può tranquillamente integrare sucessivamente (se lo si scrive bene )

[Tommo]

Interessante!
Comunque credo che nelle nuove versioni di windows il window manager è ben separato (DWM) e gira in user mode che io sappia, infatti da Vista SP1 non succede più il "blocco totale"

[Mattyfog]

anche se ci capisco poco seguo con molto interesse il thread... scusate ma se si sviluppasse un os partendo invece già da un kernel, che software bisognerebbe scrivere? cioè cosa offrirebbe già di suo il kernel e cosa mancherebbe? per caso a grabdi linee il kernel si interfaccia con l'hardware e bisognerebbe scrivere il software che infece si interfaccia fra utente e kernel e quindi appunto l'interfaccia?

[B|4KWH|T3]

Sulla Unixness o Posixness ( ):

Parlando da ignorante in materia (sono un bioinformatico): non sarebbe meglio sviluppare quest'os con le mani completamente libere e pensare poi alla compatibilità in futuro utilizzando una sandbox virtualizzata?

(scusate se ho detto una castroneria)

[cdimauro]

Originariamente inviato da Tommo

Interessante!
Comunque credo che nelle nuove versioni di windows il window manager è ben separato (DWM) e gira in user mode che io sappia, infatti da Vista SP1 non succede più il "blocco totale"

Esatto. Poi molto meglio avere un solo strato fra applicazione e driver. X lo toglierei di mezzo.

Originariamente inviato da Mattyfog

anche se ci capisco poco seguo con molto interesse il thread... scusate ma se si sviluppasse un os partendo invece già da un kernel,

Ce ne sono già qualche migliaio: le distribuzioni Linux. Inutile aggiungere confusione al caos.

che software bisognerebbe scrivere? cioè cosa offrirebbe già di suo il kernel e cosa mancherebbe?

Dipende dal kernel.

per caso a grabdi linee il kernel si interfaccia con l'hardware

Sono i driver / device che s'interfacciano con l'hardware.

e bisognerebbe scrivere il software che infece si interfaccia fra utente e kernel e quindi appunto l'interfaccia?

Le applicazioni, sì.

Originariamente inviato da B|4KWH|T3

Sulla Unixness o Posixness ( ):

Parlando da ignorante in materia (sono un bioinformatico): non sarebbe meglio sviluppare quest'os con le mani completamente libere e pensare poi alla compatibilità in futuro utilizzando una sandbox virtualizzata?

(scusate se ho detto una castroneria)

No, hai fatto bene e seguirei la stessa strada. Intanto sviluppo un s.o. nuovo / innovativo. Se poi ci tengo così tanto alla compatibilità Unix/Posix, è sufficiente relegare a un'apposita libreria esterna questo strato di compatibilità (similmente a Cygwin per Windows).

[Z80Fan]

Originariamente inviato da Tommo

Interessante!
Comunque credo che nelle nuove versioni di windows il window manager è ben separato (DWM) e gira in user mode che io sappia, infatti da Vista SP1 non succede più il "blocco totale"

Allora sono proprio sfortunato, sul 7 mi succede abbastanza

Originariamente inviato da cdimauro

No, hai fatto bene e seguirei la stessa strada. Intanto sviluppo un s.o. nuovo / innovativo. Se poi ci tengo così tanto alla compatibilità Unix/Posix, è sufficiente relegare a un'apposita libreria esterna questo strato di compatibilità (similmente a Cygwin per Windows).

Siiiii è quello che voglio fareee !!! Non leggete più quel primo messaggio del thread, le cose si sono evolute un pochino, e stò già facendo la mia strada, come ho scritto nel commento 329

[jappilas]

Originariamente inviato da M4rk191

Leggendo su Wikipedia, cercando di capire di cosa si trattasse di preciso, ho letto che X è un gestore grafico per sistemi UNIX che non gestisce l'aspetto grafico, ma solo l'integrazione tra utente e server video.

sostanzialmente è il contrario, il server X è per design quello che renderizza le primitive grafiche e il testo e disegna le pixmap a schermo, per conto delle applicazioni ( oltre a gestire la clipboard primaria e le periferiche di ingresso e redirezionare gli eventi di input) - anche se la tendenza recente è di decentralizzare tali funzionalità (per avvalersi di caratteristiche dello stack grafico qali il compositing via opengl) sono comunque previste a livello di protocollo X
quindi per dirsi compatibile un server X11 deve comunque supportarle, e un sistema su cui esso sia il fulcro (e non un' opzione, come avviene su OSX ) dello stack grafico dovrà trascinarsele dietro fintantoche non verranno deprecate (se mai ciò avverrà)

Mi chiedo, se sia assolutamente necessario un gestore grafico e se sia necessario distinguere il window manager dal gestore grafico.

la tua perplessità è lecita, e condivisa da molti tra cui il sottoscritto - il fatto è che il design di un sistema X11 deriva da una parte dall' intento di separare ciò che è "policy" (quindi cosa fare in base all' input dell' utente, cosa presentare a schermo ecc) dall' infrastruttura di basso livello (routine di disegno, driver, ecc, il cosiddetto "meccanismo") e accentrare in un singolo punto quanto più possibile del codice infrastrutturale - cosa che allo stato attuale sarebbe fattibile definendo delle API corrette e implementando in librerie condivise le routine comuni tra più applicazioni, ed eventuali elementi ad uso del server grafico in moduli/plugin di quest' ultimo
ma quando si è pensato al sistema grafico X, il supporto alle librerie non era presente in molte delle varie versioni di unix dell' epoca, e ove era presente era ancora praticamente una novità , da cui la condivisione del codice attraverso un server centrale
d' altra parte all' epoca, non si sentiva il bisogno di GUI locali ricche, complesse e reattive come le attuali, complice anche il target del sistema operativo per cui X nasceva - dovendo disaccoppiare visualizzazione ed elaborazione dell' interfaccia ad uso di mainframe, server o sistemi distribuiti, un sistema grafico network transparent era considerato un compromesso accettabile, nonostante le latenze e i round trip che il design implicava...
detto ciò, è più che lecito che una struttura come quella che si è tramandata fino ad oggi appaia "strana", anacronistica e possiiblmente inefficiente, all' esterno - in effetti lo è

[jappilas]

Originariamente inviato da Z80Fan

Beh, è utile, perchè ti permette di far comunicare la applicazioni con un server unico indipendentemente da come verrà visualizzato.

questo ce l' hai perchè il sistema grafico prevede una API che tutte le applicazioni usano, nonchè delle convenzioni (ad esempio per le coordinate schermo - peraltro il sistema di coordinate di X è considerato uno dei più illogici in circolazione) e un protocollo (non privo di ambiguità, rilevate da verifiche formali) a cui attenersi a prescindere dalla piattaforma - non è una prerogativa intrinseca di X
che mi risulti nessun programma s' interfaccia nativamente con il server X gestendo direttamente il socket(*) e il marshaling dei dati, si ha una libreria (Xlib, più recentemente XCB) che lo fa internamente e si usa la API esportata da questa

Per esempio, ci può essere compiz sopra, che allora fornisce l'accelerazione 3d e gli effetti grafici, o come detto Quartz.

l' accelerazione 3d la fornisce il driver grafico, compiz fornisce solo gli effetti

Gli so *nix non usano solo X, X è sotto e sopra c'è il desktop manager (gnome e kde + famosi) e poi ancora il windows manager (motif, metacity, compiz, quello proprio di kde...).
Windows usa un sistema centralizzato, che fà sia da "server X" che da desktop e window manager. Funziona benissimo anche questo modo,

diciamo che funziona meglio in questo modo ...

inizialmente X era stato sviluppato quando ancora si usavano i terminali stupidi per accedere ad un sistema remoto, quindi X si basa sulle connessioni di rete per inviare i messaggi alle applicazioni (oggi non più perchè il server bypassa il sistema di rete per non intasarlo).

non è esatto
il server bypassa il sistema di rete non per non intasarlo quanto perchè nel tempo ci si è resi conto che non aveva molto senso che la GUI si appoggiasse allo stack di rete quand' anche fosse stata locale...
quindi il primo passo è stato passare a un diverso transport layer (socket unix domain) e usare un tipo di socket o l' altro a seconda dei casi (ui locale o remota) mantenendo la semantica di scrittura / lettura su socket per non dover rivoluzionare il resto della code base (che all' epoca era ancora quella del server MIT poi confluita in xfree, complessa e monolitica)

. Diciamo che un sistema centralizzato è anche più veloce, poichè non ha diversi strati a cui passare le stesse informazioni

non si tratta di "strati", si tratta di altri processi user space, quindi paralleli all' X server, non sotto/sovrastanti, con cui questo comunica in senso orizzontale - il che implica passare per il kernel (che è l' unico che può scambiare dati tra due processi in spazi di indirizzamento separati) almeno due volte, una volta in un senso, una volta nell' altro

L'unico problema su Windows è che lo fanno girare in kernel mode, per questo si possono bloccare _tutte_ le finestre quando una è in mona (e a me non sò perchè mi succede spesso in windows ).

fino a XP sì, ma il DWM di Vista e 7 è un servizio userspace, dire che gira in kernel mode sarebbe una bestialità...

Quindi io per il nostro os penserei a una cosa simile ad entrambi: un server sotto che gestisce solo la comunicazione di eventi e cose del genere, ed un'altra chè avrà un collegamento diretto con quest'ultima per disegnare effettivamente le cose sullo schermo. Le applicazioni comunicheranno solo con il server.

prenderesti il peggio di un sistema come X senza risolvere nessuno dei problemi cronici di questo, solo per fare qualcosa che "assomigli ad entrambi senza essere nessuno dei due"? magari pensi anche che se in microsoft hanno risolto un problema in un certo modo, la loro soluzione va evitata perchè errata a priori...
anche se per un momento sono stato seriamente tentato di consigliarti di lasciar perdere, ma voglio provare a consigliarti come procedere - ovvero, come procederei io se si trattasse di un mio progetto
- parti dai requisiti - può sembrare banale ma fidati, non lo è, soprattutto non è banale analizzare e riconoscere i requisiti (al tempo stesso è fondamentale farlo per un sistema complesso e infrastrutturale come lo è una GUI)
quindi cosa vuoi ottenere?
window decoration fisse o modificabili?
window behaviour a sua volta fisso o modificabile?
imaging model (2d) quello standard del PDF e di librerie come Cairo o quartz, o qualcosa di diverso (tanti auguri)?
modello di IO per quanto riguarda le periferiche e in particolare la scheda grafica?
come vedi ne hai di cose a cui pensare...
- cerca di capire quale funzionalità vengono replicate nelle singole applicazioni ( ad esempio il rendering di testo e grafica - su frame buffer privati) e quali richiedono di essere centralizzate (ad esempio compositing, window management, cursore del mouse, input redirection)
- identificato tutto ciò che va centralizzato, analizza cosa va reso personalizzabile, e progetta delle API interne che consentano di implementarlo in uno singolo processo modulare con plugin
- parti dal kernel, non dalla gui - quando si progetta una sistema operativo nuovo, la gui è l' ultima cosa a cui pensare tra quelle della prima iterazione
spesso si dice che il il kernel è ciò che fa da tramite tra le applicazioni e l' hw - non è esatto, il kernel è ciò che consente a più applicazioni di condividere l' hardware in modo trasparente e sicuro, ma è anche l' elemento da cui dipendono le semantiche a cui le applicazioni si devono attenere ( tra cui il process model, il threading model, il security model, l' IO model, eccetera) e su cui queste andranno modellate quindi è la prima cosa da progettare e implementare...
a meno che non si voglia imitare un sistema preesistente basandosi sulle stesse semantiche e sulla stessa struttura di questo ( ma allora non si crea nulla di innovativo, si tratta di una mero esercizio per poter dire "lo so fare anch' io")
ma allora, consiglierei quantomeno di prendere come modello un kernel più elegante e moderno del solito *nix.. chessò, VMs, NT...

- ottimizza per il caso locale - siccome mi pare di capire che stia pensando a un sistema desktop e non il solito clone di un OS per server basato su una concezione già obsoleta, sarebbe un buon punto di partenza fare come se la rete non esistesse , e i servizi locali (same machine) fossero basati su meccanismi di IPC più efficienti (come LRPC, "active contexts" le doors o al più messaggi come quelli di binder) che non i soliti socket con read() bloccante e marshaling dei dati

[Z80Fan]

Originariamente inviato da jappilas

questo ce l' hai perchè il sistema grafico prevede una API che tutte le applicazioni usano, nonchè delle convenzioni (ad esempio per le coordinate schermo - peraltro il sistema di coordinate di X è considerato uno dei più illogici in circolazione) e un protocollo (non privo di ambiguità, rilevate da verifiche formali) a cui attenersi a prescindere dalla piattaforma - non è una prerogativa intrinseca di X

che mi risulti nessun programma s' interfaccia nativamente con il server X gestendo direttamente il socket(*) e il marshaling dei dati, si ha una libreria (Xlib, più recentemente XCB) che lo fa internamente e si usa la API esportata da questa

Se è per questo non usano neanche Xlib, usano solo le librerie di alto livello come le gtk ecc...

non è esatto
il server bypassa il sistema di rete non per non intasarlo quanto perchè nel tempo ci si è resi conto che non aveva molto senso che la GUI si appoggiasse allo stack di rete quand' anche fosse stata locale...

Era circa quello che volevo dire io, avrei dovuto scrivere (oggi non più perchè il server bypassa il sistema di rete per non intasarlo quando lavora in locale).

prenderesti il peggio di un sistema come X senza risolvere nessuno dei problemi cronici di questo, solo per fare qualcosa che "assomigli ad entrambi senza essere nessuno dei due"?

Io non voglio copiare nessuno per forza, prendo le cose che mi sembrano utili (immaginandole solo per sentito dire: non mi sono mai interessato di andare a vedere il protocollo X), e poi non ho descritto pienamente la mia idea, ho scritto 2 righe solo perchè era venuto fuori l'argomento:
"un'altra chè avrà un collegamento diretto con quest'ultima per disegnare effettivamente le cose sullo schermo."
intendevo dire qualche sorta di plugin o modulo che veniva inglobato nel server all'avvio o quando l' utente vuole cambiare; non è un programma vero e proprio, solo un insieme di funzioni che istruiscono il server su come disegnare i vari elementi sullo schermo: ad esempio un modulo base potrebbe disegnare un rettangolo quando viene chiamata la funzione "disegnaPulsante", una versione più avanzata potrebbe caricare da file una immagine, scriverci sopra il testo del pulsante e poi disegnare quello. Oppure il server si potrebbe preoccupare solo di copiare i buffer di ogni finestra nel framebuffer e lasciare alle applicazioni (e attraverso librerie caricate da queste ultime) il compito di disegnarci sopra.
Queste cmq sono solo idee, non dovete prenderle seriamente, anche perchè non c'è ancora uno scheduler e un gestore di memoria!

- parti dal kernel, non dalla gui - quando si progetta una sistema operativo nuovo, la gui è l' ultima cosa a cui pensare tra quelle della prima iterazione

Difatti ho scritto quelle due righe solo perchè è venuta fuori la discussione, non ho nessuna intenzione di sviluppare una gui adesso. Ora stò lavorando sulla SVGA (si, ho lasciato perdere il VESA) non per cominciare la gui, ma per avere un terminale testuale con risoluzione maggiore per avere a schermo le centinaia di messaggi di debug che sono abituato a mettere, tutto qui.

Cmq grazie per gli altri consigli, saranno utili quando arriveremo effettivamente alla gui

[cionci]

Quando in un futuro arriverai a scrivere un ambiente grafico... Ti ricompili e modifichi direttamente il gestore di framebuffer delle librerie Qt e vai a scrivere il window manager direttamente tramite le Qt. Poi se ci fosse da pensare ad una qualsiasi struttura alternativa....avrai sicuramente tempo.
Nota che per arrivare a quei livelli dovrai già avere un compilatore funzionante, quindi un porting della libreria standard...campa cavallo !!!