Linux progettato male?!

[Motosauro]

Originariamente inviato da cerbert

[OT]
@jappilas: mi piange un po' il cuore a dirtelo, in quanto dopo la raccomandazione di Fred Gallagher (autore di megatokyo, che gli dedica un omaggio qui: http://www.megatokyo.com/index.php?strip_id=731 ) "Haibane Renmei" è uno degli OAV che DEVO vedere.
Ma, ecco, la tua sign è un po' irregolare: una immagine+una riga di testo.

[/OT]

A buon intenditor...
Edito al volo la mia, sry (dovrei anche leggerli i regolamenti ogni tanto)

[cerbert]

Originariamente inviato da Motosauro

A buon intenditor...
Edito al volo la mia, sry (dovrei anche leggerli i regolamenti ogni tanto)

Apprezzo davvero la prudenza... ma è ancora sbagliata

b) Signature: 3 righe a 1024 solo testo con un massimo di 3 smiles dell'Hardware Upgrade Forum oppure un'immagine 100 X 50 X 5KB e una riga di testo (non deve andare a capo).

[Motosauro]

Originariamente inviato da cerbert

Apprezzo davvero la prudenza... ma è ancora sbagliata

Quelle Vitesse!
Aggiorna

[jappilas]

Originariamente inviato da cerbert

[OT]
"Haibane Renmei" è uno degli OAV che DEVO vedere.
[/OT]

ti potrei dire di guardarlo ad ogni costo e acquistare i dvd in cofanetto in edizione americana al limite (visto il mio timore che passi troppo tempo prima che la Shin Vision lo traduca) ma sembrerei troppo condizionato... però imho ne vale la pena

Ma, ecco, la tua sign è un po' irregolare: una immagine+una riga di testo.

no problem... dovendo tenere il testo così (altrimenti dovrei tornare al' avatar coi capelli verde fluo, e non mi va molto ) ero già in dubbio se togliere il link a Within the Wall <- che però raccomando, è fatto molto bene
anche perchè di siti o veri e propri Shrine, dedicati a quella serie, se ne trovano davvero tanti, e imho tutti valevoli di essere visti (e linkati, ma allora servirebbero decine di fan-code nella firma.. )

[jappilas]

Originariamente inviato da dupa

Se un giorno dovesse uscire un sistema operativo open-source ben progettato e con il relativo codice ben documentato, credo sarei la persona più felice del mondo e magari potrei farci anche un pensierino a contribuire allo sviluppo del codice.

Sinceramente credo che Linux (e le distro ad esso legate) siano troppo legate a retro-compatibilità varie per poter mai pensare di riprogettarlo per bene da zero.

Insomma serve un punto di rottura, un po' come fece la microsoft passando dai sistemi operativi che non si potevano neanche definire tali (es: windows 95) a qualcosa di più serio (windows NT)

ti dico quello che farei io -non è detto sia la soluzione ottima, ma mi sembra un buon compromesso- se dovessi creare ex novo un "kernel" (o meglio, qualcosa che assomigli a un Executive, visto che a rigori il kernel in sè e per sè è lo scheduler dei processi):
prendere un microkernel preesistente, progettato per la massima efficienza, che abbia supporto real time, una buona gestione del range delle priorità dei processi , e una IPC ottimizzata (ad esempio L4)
aggiungere in kernel space quei componenti che sotto L4 e Hurd sono implementati come demoni user space - storage, networking, audio, grafica(*) ma anche il "capability manager" e il device access subsystem - e strutturare i relativi sottosistemi in microblocchi (compartimentazione)
far sì che tali microblochi siano (presi singolarmente) rientranti, interrompibili, separati da interfacce (API/ABI) generiche invarianti, indipendenti da "cosa c'è sotto" (ad es per lo storage subsystem sia indifferente avere le unità disco su controller scsi, ata , sata, raid ecc, o per quelo di networking, ipv4 e v6 o anche ipx restino intercambiabili come ethernet, token ring, myrinet, ecc) e implementabili come moduli caricabili a richiesta o compilabili nel kernel (**)

(*) c'è una cosa che Torvalds ha detto in un' intervista che mi è sembrata logica: con un driver user space, il kernel riceve milioni di volte direttive contenenti dati e comandi da inviare all' HW grafico (notoriamente la periferica più complessa che si possa avere dentro un pc ): viene sfruttato il fatto che il kernel abbia il privilegio di accedere alle periferiche in "raw mode" senza fargli conoscere più di tanto quello che davvero fa: se invece il driver fosse interamente in kernel space la situazione sarebbe più coerente e gestibile se non altro dalle stesse persone impegnate nel kernel debugging
quindi mi riferivo principalmente al driver grafico... ma ho l' impressione che per un sistema desktop, se accuratamente progettato e debuggato può apportare grandi benefici integrare nell' executive parte del' app_server: aiuterebbe il kernel ad applicare una policy di scheduling che magari favorisca i processi con finestre in foreground o focused, e per cose come lo spostamento di una finestra l' input->reaction loop sarebbe il più breve possibile

(**) ora, si può pensare che un sistema "ancor più" monolitico sia meno gestibile di uno a microkernel avente ogni elemento come processo separato: deallocare ed eventualmente ricaricare un "kernel module" in maniera safe è possibile, in teoria anche se un modulo fosse "built in" nel kernel lo si dovrebbe poter reinizializzare
visto che alla fine, a patto di avere la lista dei kernel services o dei kernel modules "esposta" in qualche modo, tutto sta all' avere a disposizione quella manciata di comandi per console, o quel "manager" da usare in ambiente grafico
per quello che vedrei bene ad esempio, un equivalente del "gestione periferiche" di win, che però mostrasse quali moduli sono built-in e quali in forma di xyz.ko, e facesse automaticamente l' assegnazione device->driver, il modprobe e/o la ricompilazione del kernel, oltre ad andare a settare le impostazioni nel giusto namespace del DB delle configurazioni (a sua volta fornito dal progetto Elektra) qualora si aggiungessero o "spostassero" uno o più driver
Perchè per come la intendo, un progetto di Os nuovo (a maggior ragione se per desktop) dovrebbe avere al centro dell' attenzione la _consistenza_ e la _gestibilità_ oltre che le prestazionie e la stabilità: quindi per ogni componente sia in user sia in kernel mode prevedrei (almeno a grandi linee) un modo di "interagirvi" sia da console sia da ambiente visuale

[izerav]

Che ne pensate di Hurd? Arrivera` a sostituire Linux in un futuro non troppo lontano?
Per quanto mi par di capire (ma potrei sbagliarmi clamorosamente), c'e` un interesse piuttosto tiepido per lo sviluppo di questo kernel...