Home | Informazioni | Community | Sviluppo | myReactOS

  1. Home
  2. Informazioni
  3. Community
  4. Sviluppo
  5. myReactOS

  1. Descrizione
  2. Le persone di ReactOS
  3. Forum
  4. Wiki
  5. Mailing List
  6. Canali IRC
  7. Newsletter
  8. Blog
  9. FAQ per gli utenti

Community > ReactOS Newsletter Archive > ReactOS Newsletter: Newsletter 41

ReactOS Newsletter - Newsletter 41 (#41)

RSS 2.0 News Feed
Atom 1.0 News Feed

by Z98 on 2008-05-15
translated by Gabriel ilardi on 2008-05-18

Una cosa che Aleksey ha rimarcato era il concentrarsi sul bugfixing del sottosistema Win32, portandolo al livello che Wine ha da un po' di tempo. Lui pensa che bisogna non aggiungere più caratteristiche e mantenere il codice già presente, il ché dovrebbe ridurre la quantità di "rotture" e limitare il numero di regressioni. I test di Wine sono stati segnalati come un modo facile per evidenziare "rotture", anche se dovremo scrivere dei test per altri componenti noi stessi. Tuttavia, il solo fatto di trovare i bug in Win32 dovrebbe permettere a tanti programmi di girare. Gli sviluppi nel kernel stanno spostando sempre di più gli errori sul sottosistema Win32, quindi bisogna fare più attenzione allo stesso. La sua scocciatura sembra averci ripagato, poiché durante l'ultima settimana molti errori sono stati risolti. Adesso dobbiamo solo continuare su questa strada.

Ora, le priorità di Aleksey si limitano alla stabilità del SO nel suo complesso e la compatibilità con le applicazioni. La compatibilità con gli interni NT è un optional gradito, ma per il momento non porterà vantaggi immediati.

Aleksey non è stato l'unico a lamentarsi dei test di regressioni, perché Samuel, l'altro scrittore delle newsletter (teoricamente), si era lamentato per lo stesso motivo non tanto fa. Altri sviluppatori hanno suggerito delle idee, ed io ho spinto per avere il modulo rostests nelle versioni di trunk.

top

RBuild

Probabilmente spinto dalla posizione di Aleksey riguardo lo sviluppo generale, KJK ha deciso di far sentire alcune delle sue rimostranze riguardo RBuild. Questi problemi non sono nuovi e hanno annoiato molti degli sviluppatori e tester. Gli stessi vanno dalla creazione di file di soluzione per Visual Studio "scarsi" a dipendenze completamente mischiate. In tanti modi, ReactOS ha sorpassato RBuild, perché la mancanza di moduli per certe cose, implica l'inserimento di "hacks". Marc ha lavorato sodo per cercare di risolvere la maggior quantità di cose possibili, ma è troppo lavoro per una sola persona.

top

Unicode

Unicode è lo standard di codifica dei caratteri che permette la rappresentazione di fondamentalmente tutte le lingue conosciute al mondo. NT usa unicode internamente e in quasi tutto il resto. La parte difficile è tutti i dati e gli algoritmi che servono per unicode. Fortunatamente, esistono altri progetti che hanno già implementato il necessario. KJK ha deciso che proverà le dll unicode e normaliz.dll, utilizzando i Componenti Internazionali per la libreria Unicode (ICU). La libreria ICU è enorme ed ha implementato tutto quello che ci serve per Unicode, risparmiandoci lavoro. Anche Wine aveva cercato di integrare ICU una volta, ma la dimensione della libreria era problematica. Per noi, il maggior problema probabilmente sarà il fatto che ICU è scritta in C++. Abbiamo sempre avuto problemi per questo motivo, parzialmente per il compilatore C++ GCC. Fortunatamente KJK può scavalcarli.

top

NoCc

Secondo Alex Ionescu, Cc sta per Common Cache, e no Cache Controller (solo una curiosità). Comunque, Cc in ROS è sempre stato problematico. Il disegno originale era sbagliato a livello concettuale e molto probabilmente era la causa di molti problemi di instabilità. Anche se il sistema sopravvive la corruzione e sovrascrive comandato da Cc, rende il sistema più o meno utilizzabile in altri aspetti. Il problema più grave è che ROS va in crash durante la copie massicce di file, questo succede ad esempio quando viene installata un'applicazione grossa. Ma non è l'unico problema. Aleksey ha lavorato su un nuovo gestore di pool il quale è molto più restrittivo di quello che abbiamo adesso e molto più simile alla condotta NT. Abbiamo bisogno del nuovo gestore di pool per risolvere altri problemi, come fare girare OpenOffice.

Il Cc è sempre stato legato fortemente al gestore di memoria (Mm). Più correttamente, non c'è in realtà un componente chiamato Cc. Il Cc solo fornisce certi servizi al Mm. Quello che abbiamo adesso in ROS è un Mm completamente diverso da quello NT, conseguentemente anche un Cc molto diverso. La riscrittura del Mm impiegherà molto tempo e il nuovo codice di Aleksey per il pool fa parte di quello sforzo, ma per come sono legati Cc con il Mm, diventa un ostacolo importante. La soluzione corrente è la rimozione della "caching" completamente dal kernel e trasferire le richieste di lettura/scrittura direttamente ai driver dello stack di storage, ecco perché il nome NoCc. La speranza è di avere NoCc pronta per il rilascio della 0.3.5, il che potrebbe anche essere possibile.

A lungo termine, dopo che NoCc funzionerà al meglio possibile, l'intenzione è quella di aggiungere qualche algoritmo molto semplice di caching di utilizzo recente. Questo sarà ancora molto lontano da una cache comune NT, ma almeno così ci rimetteremo in strada verso un'implementazione corretta.

top

Sicurezza

Molte persone erano preoccupare riguardo l'ipotetica sicurezza futura di ReactOS, temevano che essendo un clone NT, ReactOS sarebbe vulnerabile alle stesse cose che NT. Non toccherò l'argomento, perché è ancora ipotetico e chi sa cosa porterà il futuro. Ma la gente ha fatto emergere un punto importante riguardo la sicurezza in ROS e il suo stato corrente. Ho parlato con Herve al riguardo e lui mi ha offerto spiegazioni molto esaurienti. In passato, ROS non aveva neanche l'infrastruttura per la sicurezza o l'autenticazione al di là delle normali transazioni in modo user-kernel, quindi tutti i componenti sono stati scritti tenendo in mente questo. Ne abbiamo fatta di strada da allora, con supporto per ACLs e altri controlli di sicurezza aggiunti negli anni. Il problema è che pochi componenti sono stati aggiornati per utilizzarli. Adesso, l'aggiungere questi controlli impatterà sulla performance, un fatto inevitabile. Tuttavia, è una cosa che bisogna fare o finiamo con buchi dappertutto nel sistema. Gli sviluppatori hanno lavorato per aggiungerli, ma di nuovo, ci vuole del tempo.

La maggior parte dell'infrastruttura per una sicurezza adeguata è già presente, ma siccome non è stata testata ci potrebbero essere dei bug ancora non lo sappiamo.

top

Benvenuto Steven Edwards

Premesso che Steven ancora agiva come collegamento tra ROS e Wine, aveva smesso di essere uno sviluppatore formale quando aveva dato le sue dimissioni come coordinatore del progetto nel 2006. Tuttavia, nessuno scappa veramente da noi e Steven è tornato dalla congregazione. Fortunatamente il suo ritorno fa intravedere una nuova era di cooperazione e riconciliazione tra noi e diverse parti di Wine.

top

Lingua Cinese

Questo sarebbe dovuto essere fatto tanto tempo fa, ma Klemens finalmente ce l'ha fatta a dividere la lingua Cinese in Tradizionale e Semplificata. Adesso solo devo mettermi in contatto con la gente che si era offerta come traduttori di Semplificata e far girare la ruota.

top

ReactOS Project Coordinator: Aleksey Bragin nick: fireball, Website Coordinator: Klemens Friedl nick: frik85

If the translation of the English language of this page appears to be outdated or incorrect, please check-out the English page and report or update the content.


ReactOS is a registered trademark or a trademark of ReactOS Foundation in the United States and other countries.