[C] Programmare un Sistema Operativo

[Z80Fan]

Insieme alla nuova versione, riapro il tema del nome dell' OS, in modo da aprire un server Git con il nome definitivo e sfruttare quel benedetto account SourceForge.

[Z80Fan]

http://sourceforge.net/projects/superkernel/

[dojolab]

Originariamente inviato da Z80Fan

Insieme alla nuova versione, riapro il tema del nome dell' OS, in modo da aprire un server Git con il nome definitivo e sfruttare quel benedetto account SourceForge.

MyOS?

[Takuya]

kOS - kool Operating System?

[dojolab]

Originariamente inviato da Takuya

kOS - kool Operating System?

HWOS

[Tommo]

Continuo a dire che non puoi avere un nome originale senza una funzione o un obiettivo originale

Sparo a caso:
-YAOS, Yet Another OS (che spiega tutto)
-caOS, inventati il significato di ca. Il logo sarebbe tipo quello di Spore
-Uno (in onore di PK ) (ma è già preso per la mia rivoluzionaria IA)
-Mark 0
-MyOS

Sennò tra nomi di pianeti e quant'altro c'è da sbizzarrirsi, o perchè non animali

[DanieleC88]

Originariamente inviato da Tommo

-caOS, inventati il significato di ca.

Eh no, troppo tardi. Quello era il nome che alla fine avevo dato al mio famoso sistema operativo.

[dojolab]

Originariamente inviato da Tommo

Continuo a dire che non puoi avere un nome originale senza una funzione o un obiettivo originale

Sparo a caso:
-YAOS, Yet Another OS (che spiega tutto)
-caOS, inventati il significato di ca. Il logo sarebbe tipo quello di Spore
-Uno (in onore di PK ) (ma è già preso per la mia rivoluzionaria IA)
-Mark 0
-MyOS

Sennò tra nomi di pianeti e quant'altro c'è da sbizzarrirsi, o perchè non animali

CaccamOS?

[Z80Fan]

-YAOS, Yet Another OS (che spiega tutto)

O anche Pinos (pinos is not an os)

-Uno (in onore di PK ) (ma è già preso per la mia rivoluzionaria IA)

Poi ovviamente me la compili così la uso come console vero?

-Mark 0

Diciamo Mark -1 visto le funzionalità attuali

-MyOS

http://www.myos.org/

Sennò tra nomi di pianeti e quant'altro c'è da sbizzarrirsi, o perchè non animali

Avevo anche pensato a nomi italiani, tipo Leonardos.
(Ovviamente non è necessario metterci OS alla fine, solo se suona bene)


Discutiamo anche di questo: che funzioni vorreste avere implementate in un OS? Sia da lato "utente" (cioè ad esempio sull'interfaccia), sia dal lato "programmatore" (librerie, utilità di programmazione tipo Visual*)...
Scrivete qualsiasi cosa vi passi in mente, non importa quanto strana o complessa

[dojolab]

Originariamente inviato da Z80Fan

Discutiamo anche di questo: che funzioni vorreste avere implementate in un OS? Sia da lato "utente" (cioè ad esempio sull'interfaccia), sia dal lato "programmatore" (librerie, utilità di programmazione tipo Visual*)...
Scrivete qualsiasi cosa vi passi in mente, non importa quanto strana o complessa

Shell Python.

[Tommo]

Dunque... vorrei un file explorer veramente fluido, anche meglio di quello di Mac OS X: qualcosa che riesca a mostrare una gerarchia di folders in una stessa schermata, permettendo di spostare e lavorare sui files di tutti i livelli.
E voglio che tutta l'interfaccia sia pensata per il single click + drag&drop.
Magari falla anche con azioni scriptabili con blocconi visuali trascinabili e configurabili.

Poi ci voglio un "clipboard shelf" che esce fuori quando copi qualcosa, come la barra di mac:
Ctrl+C quindi invece di copiare una sola cosa e rimpazzare la vecchia, si va ad aggiungere alle "note" precedenti: quindi per incollare basta fare doppio click sull'icona col mouse, o premere Ctrl+0...9, o Ctrl+V per la testa della pila.
Non so quante volte avrei pagato oro per una cosa del genere.

Poi ci voglio un supporto al threading avanzato nativo, che espone API basate sul pattern del Task Dispatcher tipo Intel TBB, Poco o JobSwarm.

Poi servirebbe un sottosistema grafico 2D completamente basato sulla scheda video, che offre 3 livelli:
-uno openGL like per disegnare in HW set di dati sui vertici
-uno tipo Quartz/WPF che usa il "parent" per disegnare primitive grafiche come immagini linee e quant'altro.
-il più alto usa il 2° per disegnare finestre standard configurabili da file di dati.

Anche una repository di programmi e SDKs non gestibili a mano ma solo da una routine del SO sarebbe eccellente, riducendo il casino pazzesco dei vecchi SO.
Insomma, l'installer dovrebbe essere parte del sistema operativo, e dovrebbe tenere traccia di tutti i file eseguibili che entrano ed escono.
Un programma non trattato dall'installer non parte.

Poi le applicazioni dovrebbero avere un protocollo stringente di chiamate dal/al SO, il cui rispetto viene validato dall'installer: ad esempio dovrebbero riferire quando hanno finito di accendersi, di caricare, dovrebbero chiedere il permesso quando stanno per iniziare qualcosa di pesante, e notificare quando finiscono.
Allo stesso tempo il SO può notificare il suo stato e aspettarsi che le app facciano qualcosa, come nel caso dello sleep che non sarebbe un dump dello stato della memoria, ma una cosa fatta a mano da ogni applicazione, che salva i dati strettamente necessari su disco.
Con una cosa del genere, si potrebbe anche mettere in sleep selettivamente una sola applicazione pesante e usare il pc per altro
Il che ci porta ad aggiungere un terzo stato all'esecuzione delle applicazioni: Attivo, in Background e Congelato.

Ah, OGNI SINGOLA transazione di rete passa attraverso il SO, sennò viene bloccata. E il SO volendo può loggare tutti i dati emessi e ricevuti da un'app.
Quando un'app richiede accesso in scrittura o in lettura, l'installer lo fa presente all'utente.

In sostanza tra questo e la cartella schermata, è del tutto impossibile smanacciare con le applicazioni, sia per l'utente sia per i malintenzionati; inoltre le applicazioni non sono più in posizione di comando sul sistema operativo: essendo ospiti, devono comportarsi educatamente e chiedere permesso

Sarebbe utilissimo per cose tipo le applicazioni che si aprono all'avvio, che potrebbero essere fatte partire una dopo l'altra sul segnale di "load complete" della precedente, senza intasare il sistema accendendosi tutte assieme (vero windows?).
Oppure per segnalare all'utente "il sistema è sotto carico, vuoi davvero continuare e scrivere sto DVD", o per sapere se un'App è a schermo intero, o se consuma batteria, o se emette suoni, etc.

E tanta tanta altra roba

Anche se comprendo che al 99% non arriverai nemmeno vicino a questo tipo di problemi

[Slayer86]

Tommo... sei un genio...la maggior parte delle cose che hai scritto non le avevo nemmeno pensate! XD
Certo con un simile sistema sarebbe improponibile il porting di qualsiasi applicazione scritta per altri OS...

Però alcune chicche... come lo stack per il copia incolla sarebbe da proporre agli sviluppatori di qualche DE open...

[Tommo]

Originariamente inviato da Slayer86

Tommo... sei un genio...la maggior parte delle cose che hai scritto non le avevo nemmeno pensate! XD
Certo con un simile sistema sarebbe improponibile il porting di qualsiasi applicazione scritta per altri OS...

Però alcune chicche... come lo stack per il copia incolla sarebbe da proporre agli sviluppatori di qualche DE open...

Grazie
Comunque spinto dalla gegnalità dell'idea dello stack (che m'è venuta mentre scrivevo tra l'altro) ho guardato su internet come realizzarla... ed esiste già, almeno per Mac:
CopyPaste Pro
Peccato

Certo integrata nel SO funzionerebbe meglio.

Comunque i modi per rivoluzionare un SO moderno sarebbero veramente tanti, anche per questo Linux non mi è simpatico: è tutto libero, tutti decidono tutto... e poi sono i primi ad attaccarsi a tradizioni decennali come la riga di comando, server X e compagnia bella.
Poi arriva Apple, che è chiusa e cattiva, e con IOS cambia tutte le carte in tavola
Infatti il 99% delle idee nel mio post zitte zitte vengono dall'architettura di quello

[LS1987]

Forse prima di pensare al nome non sarebbe meglio pensare alle sue funzionalità o al suo obiettivo, e in base ad essi pensare un nome adeguato?

[khelidan1980]

Originariamente inviato da Tommo

Grazie
Comunque spinto dalla gegnalità dell'idea dello stack (che m'è venuta mentre scrivevo tra l'altro) ho guardato su internet come realizzarla... ed esiste già, almeno per Mac:
CopyPaste Pro
Peccato

Se ho capito bene esiste pure per win:

http://bluemars.org/clipx/

[cdimauro]

Per il nome ecco la soluzione definitiva:

BaldiOS

e non c'è storia: ho anche tonnellate di materiale, pure di merchadising. Roba che Linux può soltanto sognarsi:

A parte che Tux finirebbe affettato.

[blackskop]

rockOS

[Z80Fan]

Originariamente inviato da dojolab

Shell Python.

Erà già nei miei piani, visti i precedenti consigli di altri utenti.

Originariamente inviato da Tommo

Dunque... vorrei un file explorer veramente fluido, anche meglio di quello di Mac OS X: qualcosa che riesca a mostrare una gerarchia di folders in una stessa schermata, permettendo di spostare e lavorare sui files di tutti i livelli.
E voglio che tutta l'interfaccia sia pensata per il single click + drag&drop.
Magari falla anche con azioni scriptabili con blocconi visuali trascinabili e configurabili.

Ok.

Poi ci voglio un "clipboard shelf" che esce fuori quando copi qualcosa, come la barra di mac:
Ctrl+C quindi invece di copiare una sola cosa e rimpazzare la vecchia, si va ad aggiungere alle "note" precedenti: quindi per incollare basta fare doppio click sull'icona col mouse, o premere Ctrl+0...9, o Ctrl+V per la testa della pila.
Non so quante volte avrei pagato oro per una cosa del genere.

Si, è un'idea geniale!

Poi ci voglio un supporto al threading avanzato nativo, che espone API basate sul pattern del Task Dispatcher tipo Intel TBB, Poco o JobSwarm.

Anche come Grand Central Dispatch? Cmq vedrò quando implementerò lo scheduler.

Poi servirebbe un sottosistema grafico 2D completamente basato sulla scheda video, che offre 3 livelli:
-uno openGL like per disegnare in HW set di dati sui vertici
-uno tipo Quartz/WPF che usa il "parent" per disegnare primitive grafiche come immagini linee e quant'altro.
-il più alto usa il 2° per disegnare finestre standard configurabili da file di dati.

Mi sembra un buono stack. Cosa intendi dire per "completamente basato sulla scheda video"? Che è studiato per prendere il meglio dalle nuove tecnologie?

Anche una repository di programmi e SDKs non gestibili a mano ma solo da una routine del SO sarebbe eccellente, riducendo il casino pazzesco dei vecchi SO.
Insomma, l'installer dovrebbe essere parte del sistema operativo, e dovrebbe tenere traccia di tutti i file eseguibili che entrano ed escono.
Un programma non trattato dall'installer non parte.

Capito, come succede su Android no? L'applicazione (o almeno il suo file di installazione) deve definire i servizi che l'applicazione accederà.

Poi le applicazioni dovrebbero avere un protocollo stringente di chiamate dal/al SO, il cui rispetto viene validato dall'installer: ad esempio dovrebbero riferire quando hanno finito di accendersi, di caricare, dovrebbero chiedere il permesso quando stanno per iniziare qualcosa di pesante, e notificare quando finiscono.
Allo stesso tempo il SO può notificare il suo stato e aspettarsi che le app facciano qualcosa, come nel caso dello sleep che non sarebbe un dump dello stato della memoria, ma una cosa fatta a mano da ogni applicazione, che salva i dati strettamente necessari su disco.
Con una cosa del genere, si potrebbe anche mettere in sleep selettivamente una sola applicazione pesante e usare il pc per altro
Il che ci porta ad aggiungere un terzo stato all'esecuzione delle applicazioni: Attivo, in Background e Congelato.

E' una buona idea; tuttavia, è un po' utopistica: come puoi fidarti delle applicazioni? Finchè le scrivi te è un conto, ma secondo te un programmatore che vuole far sembrare la sua applicazione velocissima, seriamente chiederebbe il permesso all'OS che *potrebbe* rallentarla (anche se con un motivo valido)?
In secondo luogo, dover gestire tutti questi eventi allungherebbe la scrittura del programma, quindi: o si lascia l'opzione al programmatore se gestire o meno gli eventi, e la maggior parte delle applicazioni non la userà, oppure metterlo d'obbligo facendo quindi allontanare tutti quei programmatori suddetti che non hanno voglia di gestire tutti questi dettagli.

Ah, OGNI SINGOLA transazione di rete passa attraverso il SO, sennò viene bloccata. E il SO volendo può loggare tutti i dati emessi e ricevuti da un'app.
Quando un'app richiede accesso in scrittura o in lettura, l'installer lo fa presente all'utente.

Perchè, non funziona così anche adesso?

In sostanza tra questo e la cartella schermata, è del tutto impossibile smanacciare con le applicazioni, sia per l'utente sia per i malintenzionati; inoltre le applicazioni non sono più in posizione di comando sul sistema operativo: essendo ospiti, devono comportarsi educatamente e chiedere permesso

Bisogna vedere però se tutte questi sistemi di protezione poi non influiscano negativamente sulla facilità d'uso del sistema: se i settaggi o le richieste di conferma sono troppo complesse, l'utente accetterà senza nemmeno guardare (difatti si è visto con Android che neanche dell'utente non ci si può fidare, a meno che non sia un power user che setta tutto a puntino)

Sarebbe utilissimo per cose tipo le applicazioni che si aprono all'avvio, che potrebbero essere fatte partire una dopo l'altra sul segnale di "load complete" della precedente, senza intasare il sistema accendendosi tutte assieme (vero windows?).

In questo caso avere il "load complete" porterebbe a dei vantaggi.
In effetti, si può lasciare non obbligatorio la scrittura delle gestioni, ma in questo caso, lo scheduler prenderà questi programmi con una priorità inferiore a quelli che la gestiscono (così i programmatori saranno incentivati maggiormente a rispettare le regole).

Anche se comprendo che al 99% non arriverai nemmeno vicino a questo tipo di problemi

Non ho mica detto che servono per il mio os (in realtà si )

Originariamente inviato da LS1987

Forse prima di pensare al nome non sarebbe meglio pensare alle sue funzionalità o al suo obiettivo, e in base ad essi pensare un nome adeguato?

L'idea era di fare un os desktop general-purpose.

@cesare & blackskop
Ok, ma non banalizziamo, questo è un progetto S E R I O !

[Tommo]

Originariamente inviato da Z80Fan

Anche come Grand Central Dispatch? Cmq vedrò quando implementerò lo scheduler.

Yeah proprio tipo quello
Lo scopo è impedire in qualsiasi modo che le app sappiano su quanti cores stanno girando, per permettere al programma di scalare su un numero arbitrario di cores di potenza variabile in futuro.

Originariamente inviato da Z80Fan

Mi sembra un buono stack. Cosa intendi dire per "completamente basato sulla scheda video"? Che è studiato per prendere il meglio dalle nuove tecnologie?

Intendo che non usa la CPU per nessun compito visuale, e tutta l'interfaccia alla fine della storia è renderizzata in OpenGL dalla memoria della scheda video.
La CPU ai vari livelli si limita ad assemblare le views e mandare in memoria le risorse necessarie.

Originariamente inviato da Z80Fan

E' una buona idea; tuttavia, è un po' utopistica: come puoi fidarti delle applicazioni? Finchè le scrivi te è un conto, ma secondo te un programmatore che vuole far sembrare la sua applicazione velocissima, seriamente chiederebbe il permesso all'OS che *potrebbe* rallentarla (anche se con un motivo valido)?
In secondo luogo, dover gestire tutti questi eventi allungherebbe la scrittura del programma, quindi: o si lascia l'opzione al programmatore se gestire o meno gli eventi, e la maggior parte delle applicazioni non la userà, oppure metterlo d'obbligo facendo quindi allontanare tutti quei programmatori suddetti che non hanno voglia di gestire tutti questi dettagli.

sicuramente allunga i tempi, di sviluppo: sia i tuoi, perchè dovrai validare le chiamate delle app facendole testare ad una persona vera (come fanno Apple , Google e MS) sia perchè va implementato tutto il protocollo che interessa l'applicazione (non tutte sono interessate a tutti gli aspetti del protocollo, anzi).

Di contro hai meno applicazioni, ma di conseguenza anche meno cloni e molta più qualità; vedila così:
quando vai a cercare la qualità vera sui sistemi correnti, devi implementare le stesse chiamate che offrirebbe il tuo SO, ma con hack assortiti.
Questo a scapito della portabilità tra versioni del SO e della stabilità.

Es: in windows migliaia di applicazioni usavano hardcoded path per salvare i propri settings in Documents and Settings, e nel peggiore dei casi in Program Files (che con Vista è diventato read-only), quindi scassandosi col cambio di nomi e privilegi
Nel tuo sistema invece, dotato di questo famoso protocollo, potresti dedicare ad ogni app uno spazio virtuale sul filesystem, dove piazzare salvataggi e impostazioni, che si accede con una propria interfaccia.
Questo andrebbe a scapito di chi fa un txt a tirar via, ma migliorerebbe considerevolmente la vita di chi vuole fare le cose fatte per bene.
(e ti permetterebbe di disinstallare l'applicazione in modo pulito, anche).
Per quanto riguarda applicazioni che _creano_ dei files, boh. Però avendo separato i file di impostazione, possiamo assumere che tutti gli altri siano dati creati per precisa volontà dell'utente, e quindi possono risiedere solamente nella sua cartella (che anche quella è sandboxed).
Così impedisci del tutto alle app di fare cazzate coi files in giro per il sistema, tipo virus che modificano dll, applicazioni che modificano se stesse o altre porcherie assortite.

Quindi indubbiamente ti perdi la fascia di mercato delle applicazioni non interessate alla qualità, e questo io lo vedo come un vantaggio

Originariamente inviato da Z80Fan

Bisogna vedere però se tutte questi sistemi di protezione poi non influiscano negativamente sulla facilità d'uso del sistema: se i settaggi o le richieste di conferma sono troppo complesse, l'utente accetterà senza nemmeno guardare (difatti si è visto con Android che neanche dell'utente non ci si può fidare, a meno che non sia un power user che setta tutto a puntino)

No le autorizzazioni dovresti tenerle il più possibile tra l'app e il sistema, lo scopo è evitare che l'user debba dare permessi di amministratore o roba del genere...

Originariamente inviato da Z80Fan

Perchè, non funziona così anche adesso?

Beh, dato che possono esistere backdoors e quant'altro qualcosa di diverso c'è.
Insomma, il succo è che l'utente, e quindi anche il SO, possono tenere traccia di tutte quante le connessioni attive e ricondurle alla data applicazione.
Una specie di task manager ma con le connessioni, insomma.
Il tutto con DNS di destinazione e traffico in chiaro.

Se ci aggiungi che un'app può accedere solo alle sue impostazioni ed ai dati dell'utente, il sistema è di diverse lunghezze più sicuro di quelli odierni, in quanto una backdoor dovrebbe essere già contenuta nel programma che l'utente scarica (niente trojan), e quel programma viene visionato da te e poi dall'installer (niente virus).

Riassumendo tutti i punti: metti tutto in una sandbox, e poi la sandbox in un'altra sandbox

[grigor91]

SolidOS: a rock-solid operating system.