Google non blinda i suoi forzieri

Re: Però...
- Scritto da: FDG[cut]
Tuttavia, per quanto apprezzi che qualcuno abbia
speso energie per far rivivere questo sistema
operativo, non condivido la scelta di rifare
esattamente BeOS. Cioè, per me aveva senso
puntare sulla filosofia piuttosto che decidere di
mantenere tutto, anche quello che c'era di
sbagliato.L'idea iniziale per la R1 era quella di realizzare un cloneopen source con tanto di compatibilità binaria.Nel corso del tempo tale obiettivo è cambiato: la compatibilitàcon BeOS è tuttora importante anche solo per riutilizzareapplicazioni, non più mantenute, in un primo momento (in attesadi nuovi programmi). Tale compatibilità ha un altro vantaggio cioèquello di rimanere, almeno all'interno della R1, saldamente fermiad una API già definita evitando perdite di tempo.Ciò comporta anche la possibilità di mantenere i principisecondo i quali BeOS è stato realizzato evitando di perderliper strada.Questo obiettivo non è certamente quello finale, per quanto glisviluppatori abbiano sempre ripetuto che le migliorie più grosse sonodestinate alla R2 ho notato che l'opinione generale è cambiatanel corso del tempo.Ormai BeOS non gira più sui computer recenti, ciò significa chenon esiste più la caccia all'ultima versione trafugata da Internet,o dell'ultima incarnazione non ufficiale della R5 con componenti leggermente aggiornatinella speranza di vederlo girare sul proprio PC.Da lunedì chi vuole provare BeOS, installerà Haiku.Ora che Haiku inizia a giocare duro sia gli utenti che gli sviluppatorisi accorgono che è necessario modernizzarlo.E ciò sta già accadendo, senza stravolgimentidella API per carità, ma basti pensare alle recenti novità comeil WiFi in lavorazione, Bluetooth, SATA, l'integrazione di OSS e Gallium attualmente in lavorazione che porterà auspicabilmente gli stessi driver open source accelerati che saranno disponibili su Linux.L'introduzione di Gallium comporta alcune modifiche all'app_server, modifiche non certo di pertinenza di un clone al 100% di BeOS.Oppure le modifiche all'Interface Kit per supportare i layout ispirati a quelli delle Qt. Al tempo con BeOS ricordo che il posizionamento delle varie viste era veramente fastidioso, bisognava specificare a manoni la posizione e la dimensione del rettangolo, oggi con i layout questoavviene in maniera automatica.Oppure ancora le icone vettoriali poco pesanti per l'elaborazione e l'occupazione su disco, infatti Haiku usa il suo formato denominato HVIF in barba a SVG.Quindi si può dire che l'obiettivo è quello di non tradire le origini, mantenere la compatibilità con BeOS ma allo stesso tempo creare nuove funzionalità o tecnologie che in BeOS non esistevano.La GUI stessa non è più identica a quella di BeOS, è molto simile ma ha una sua "personalità" e questo rappresenta in maniera emblematica ciò che voglio dire.
Intanto, ricordiamoci che BeOS è un sistema
operativo monoutente. Al giorno d'oggi è
improponibile per varie ragioni, tra cui la
sicurezza. Devi avere la possibilità di
compartimentare il sistema. Poi, il framework,
cioè le classi C++ con cui si sviluppava, non
implementava i necessari pattern che poi sono
diventati di uso comune. Ad esempio, non era
previsto il concetto di controller, cosa che ti
costringeva a creare tante sottoclassi dei widget
di cui dovevi personalizzare il comportamento
(anche per le cose più banali come decidere che
contenuto dovesse avere una finestra). Più altre
cosucce che potevano essere riviste, a partite
dalla stessa
interfaccia.Per quanto riguarda la multiutenza so che il lavoro è stato parzialmente svolto non so quanto manchi, ma penso che sia una preoccupazione per la R2 - o almeno spero che lo sia se è una funzionalità che porta via molto tempo. Mi spiego meglio: a livello di feature Haiku ha già oggi qualcosa che non c'era in BeOS quindi penso che ci si possa accontantentare di attendere la R2 per la multiutenza se questo significa accelerare il rilascio della R1. Perchè il grosso delle novità arriverà con la R2.Per quanto riguarda invece le API, se non ho frainteso, anche con altre API più complete come le Qt 4.x eredite da classi base che hanno delle funzionalità minime, al fine di implementere qualcosa in più. Non mi sembra quindi un enorme problema, almeno paragonando la API di Haiku con analoghe controparti open source.